Last November we announced a backend upgrade to the DAP Query API / CD2 API that brought higher data fidelity and a more reliable replication pipeline. Catalog data is the last namespace still served from the previous infrastructure. We're now moving it onto the same upgraded backend that every other namespace already runs on. The change is happening on June 30th.
What's changing?
The catalog namespace is moving onto the same upgraded pipeline that already powers the rest of the DAP Query API. Same API, same client, same namespace path — only the engine behind it changes. The result is faster queries, more predictable scaling, and a consistent platform for every dataset we publish.
Action required: take a fresh snapshot
Because data is being re-materialized from a new source, you'll need to take a fresh snapshot of any tables you depend on after the cutover. Incremental syncs against pre-cutover states won't be valid.
If you have an existing integration, plan a one-time snapshot run for each table you use, then resume your normal incremental schedule from there.
If your incremental request uses a 'since' parameter that predates the available data, the API will return an HTTP 400 error advising you to drop the table and initiate a fresh snapshot to ensure data consistency and accuracy.
Rollout schedule
This rollout is different from the last one. Instead of a per-region staggered window, we're cutting over all regions on the same day.
Event | Date |
|---|
Cutover (all regions) | 2026 June 30, starting at 12:00 UTC |
Expected maintenance window | 4 hours |
During the maintenance window the DAP Query API / CD2 API will be unavailable in every region.
Schema changes you should know about
We've aligned the published Catalog data with our dap-schemas definitions. Most fields are unchanged, but a few have type changes that could affect strictly typed pipelines or downstream warehouses. The ones below are worth a closer look.
Monetary fields change type but not value
In the current Parquet output, several decimal columns are serialized as int32, which drops the fractional part. After the cutover they'll be serialized as int64 to match the schema. Expect both the type and the numeric value to change (for example, 15 becomes 15.00).
Affected fields:
- order_items.amount, order_items.unit_price, order_items.discounted_amount
- orders.total
- payments.amount
- products.enrollment_fee, products.credits
- promotions.amount
- bulk_checkout_promotions.discount, cart_item_promotions.discount, order_item_promotions.discount
If your pipeline casts these to integers, treats them as cents, or sums them as integers, update those steps before the cutover.
Soft deletes now included in incremental data
Incremental responses include an action field that indicates whether a record was updated (U) or deleted (D). Because Catalog data was previously backed by a different technical solution, the action field could only ever return U — there was no way to signal a deletion.
After the cutover, the Catalog namespace will behave consistently with every other namespace: soft-deleted records will appear in incremental responses with action: D.
If you’re not using the DAP CLI and have a custom integration that processes incremental Catalog data, make sure your pipeline accounts for action: D records after the cutover.
Using the DAP CLI? No action needed
If you're consuming Catalog data through the DAP CLI, the client will handle the schema changes and soft deletes for you out of the box. Once you've taken your post-cutover snapshot, incremental syncs will resume as usual.
What this means for you
- Faster queries and a more scalable backend. Catalog data joins the rest of DAP on the upgraded infrastructure.
- Catalog data through the same API. No new client, no new auth, same namespace.
- Schema that matches the docs. Types in the delivered data will line up with the published dap-schemas, which makes downstream modeling more predictable.
What to do before the cutover
- Review the catalog namespace docs if you plan to consume Catalog data.
- Audit any pipeline that consumes the fields listed above, especially monetary columns.
- Plan a fresh snapshot run for the tables you depend on, scheduled for after the maintenance window.
If you have questions, please reach out to our support team.
