Which Notion API rate limit strategies prevent production failures during high-load data synchronization?

When transitioning a Notion integration from a local development environment to a production workspace, the application often encounters unexpected request failures. While local testing with small datasets rarely triggers throttling, production workloads involving large-scale page synchronizations frequently hit the API rate limits.

The Notion API requires a Notion-Version header and utilizes a Bearer token for authentication. In high-load scenarios, the official SDK does not automatically manage the retry logic for 429 (Too Many Requests) responses, leaving the implementation of backoff strategies to the developer.

What is the recommended pattern for implementing an exponential backoff mechanism that aligns with Notion's specific rate-limiting windows? Does the API provide a header indicating the exact wait time before the next request can be successfully processed?