- Overview
- API Resources
Supply Chain & Retail Solutions API guide
Every table uses scheduled ingestion: incoming rows are accepted and buffered as they arrive, and flushed to the warehouse on a per-table cron schedule. The default schedule is every 30 minutes (*/30 * * * *); the cron can be customized per table on request.
How it works
The endpoint, headers, and request body are unchanged from the standard ingestion flow. What you should know about the lifecycle of accepted rows:
- Successful rows are accepted into a per-table buffer.
- At the next cron tick, buffered rows are validated (see Validation behavior) and written to the warehouse in a single batch.
- A
200 OKresponse confirms the rows were accepted and buffered — not that they have been written to the warehouse.
Validation feedback (any failed rows in the response's failed array) is returned in the same way regardless of the cron timing. Failed rows also surface in the matching <table_name>_failed_rows tables and the Data Quality Dashboard.
Cron format
Schedules are configured per table using a standard cron expression. Both Quartz (six fields, including seconds) and Unix (five fields) cron formats are supported. Some examples:
| Expression | Format | Meaning |
|---|---|---|
*/30 * * * * | Unix | Every 30 minutes (default) |
0 0 2 * * ? | Quartz | Every day at 02:00:00 |
0 0 * * * ? | Quartz | At the top of every hour |
0 */15 * * * ? | Quartz | Every 15 minutes |
0 2 * * * | Unix | Every day at 02:00 |
Times are interpreted in UTC. Very high-frequency schedules (sub-minute) are rejected.
Behavior between scheduled runs
- Between runs, the connector that writes rows from the buffer to the warehouse is idle. No data is moved.
- At the configured cron time, the platform activates the connector. Buffered rows for that table are validated and written to the warehouse in a single batch.
- After the batch completes, the connector returns to idle until the next cron tick.
If a scheduled run is missed (for example, because the platform was unavailable at the cron time), buffered rows are not lost — they are flushed at the next successful run.
This idle / active cycle is managed by the platform — there is no API for you to start, stop, or step it.
Inspecting outcomes
- The HTTP response on each ingest call confirms whether the rows were accepted into the buffer and reports any validation failures detected before the response.
- The Data Quality Dashboard in your Peak tenant shows aggregate outcomes for each scheduled run — record counts, pass rate, top error codes, and the exact failed rows. Use the time-range filter to inspect a specific run.
- Failed rows from asynchronous validation appear in the matching
<table_name>_failed_rowstables.
Customizing the schedule
The default schedule of every 30 minutes works for most cases. To change the cron for one or more tables — for example, daily at 02:00 UTC for a low-volume reference table, or every five minutes for a near-real-time table:
- Submit a support ticket listing the solution name, the tables, and the desired cron expression for each.
- Confirm the schedule with your Peak contact — very high-frequency schedules (sub-minute) are rejected.
- Once changed, your existing API integration continues to work without code changes; only the timing of the warehouse write changes.
To revert a table to the default schedule, or change it again later, submit a follow-up ticket. Buffered rows are flushed once before the schedule change takes effect.