Skip to main content

The problem

When repeatedly querying a transaction or order status, you may receive this error:

Why this happens

This block protects both the platform and producers. When you make multiple query requests in a short period of time, known as polling, you overload servers and may affect performance for other producers. {settings.title} is designed to work asynchronously:
  • You create a transaction and receive a confirmation ID.
  • You wait for payment, such as Pix or card.
  • You receive update notifications through webhooks.

Correct flow

The correct architecture does not require repeatedly checking status:
  1. When creating a transaction, send the callbackUrl parameter with the URL of your server that will receive notifications.
  2. When the transaction status changes, for example from PENDING to PAID, {settings.title} sends a webhook to your callbackUrl.
  3. Your server processes the webhook and updates the order status internally.
See the Webhooks documentation for more details.

When to use queries

Query routes, such as /v1/transactions, should be used only when necessary, for example:
  • You have not received the webhook after a reasonable time, such as more than 5 minutes.
  • For reconciliation, to check if any transaction was not notified.
  • For one-off support checks.

How to resolve it

If you are receiving this error, change your application flow to use webhooks:
  1. Configure a webhook by sending callbackUrl when creating the transaction.
  2. Implement an endpoint on your server to receive notifications.
  3. Remove polling loops from your code.
  4. Store the transaction ID for future manual queries when necessary.

Implementation example

Summary

  • The error happens when you repeatedly query status through polling.
  • {settings.title} is designed for asynchronous notifications through webhooks.
  • The solution is to implement webhooks and remove polling from your code.
  • Use queries only as a fallback when a webhook is not received.