Skip to main content
Base only reacts to changes when you explicitly configure it to. Automatic Actions are “IF X happens, THEN do Y” rules you set up directly in the Base panel, both globally and within specific integration settings (for example, Integrations → Amazon → Order Statuses). Choosing the right mechanism for your integration determines how quickly and reliably your system learns about important order events.

​
Three ways to catch a change on an order

​
1. Automatic Action in Base

Create a rule such as “if a cancellation request arrives from the marketplace, set status to Cancelled.” The action runs entirely on Base’s side, so no extra logic is required in your own system. This is the simplest approach to maintain and works well for straightforward workflows like auto-assigning statuses or triggering internal notifications.

​
2. Polling getJournalList

getJournalList returns a list of order events from the last 3 days, including order confirmation and cancellation events.
getJournalList is disabled by default. Enable it in the Base panel under My account → API before using it.
Poll this endpoint regularly to discover events your system may have missed; it acts as a reliable catch-up mechanism alongside webhooks.

​
3. Webhook (“Call URL” action)

A webhook is a “Call URL” Automatic Action. When the watched event occurs, Base immediately calls your defined URL and passes the order ID along with any optional parameters you specify (for example, &cancel=1) or values pulled directly from the order, similar to variables available in email templates. This is usually the fastest way to catch an event in real time without polling.
Design your webhook receiver around these constraints; they’re not configurable:
  • It’s a HEAD request, not a POST. There is no request body; any data Base needs to pass has to be encoded into the URL itself (query parameters or path segments), the same way you’d build a variable into an email template.
  • Tight timeouts. Base allows roughly 3 seconds to connect and 5 seconds total for the request. If your endpoint doesn’t respond in time, the call is treated as failed. Do heavy processing asynchronously: acknowledge fast, then work the queue.
  • Any 2xx status counts as success. Anything else (including a timeout) is treated as a failure.
  • No automatic retry. A failed delivery is not queued or retried, which is exactly why the recommended pattern below pairs webhooks with polling as a safety net.
  • Duplicate deliveries are possible. Build your handler to be idempotent: for example, check the order’s current status before acting, rather than assuming each call represents a new event.
  • Limited ordering guarantee. Multiple actions configured within the same automatic-action block run sequentially in the order you defined them, but there’s no ordering guarantee across different orders, different action blocks, or different event types.
  • A timeout on your end doesn’t prove nothing happened. Even if your response times out, your handler may have already started or finished processing. This is another reason to make the handler idempotent rather than relying on “no response received” to mean “nothing to undo.”
  • No cryptographic signature. Base does not sign these requests or send an HMAC or Authorization header. The only authentication-adjacent header is a weak X-BL-UID-UNCONFIRMED value, which is not sufficient to verify the call actually came from Base. Embed your own secret token as a query parameter in the Call URL you configure, and check for it on your end.

​
Most common use case: catching a cancellation

A customer requests to cancel an order on a marketplace, Base records the cancellation, and you need to find out before you ship the order unnecessarily. The recommended solution combines all three approaches:
  • An Automatic Action directly sets the order status to Cancelled or Rejected as soon as the cancellation request arrives.
  • A webhook notifies your system immediately so you can halt fulfillment. Your handler can then call setOrderStatus to update the order status in Base programmatically.
  • A getJournalList poll catches any events the webhook may have missed.
See Order Statuses for guidance on which status to assign to cancelled or rejected orders.

​
Delivering tracking numbers and invoices to the marketplace

Forwarding a tracking number or invoice back to the order source is often tied to a specific status and is not instant: Base processes these updates in scheduled batches on the backend rather than the moment you make the API call. The exact schedule and timezone aren’t publicly documented and vary by integration and update type, so don’t build integration logic that assumes a specific delivery time. Plan for an asynchronous delay of up to a few hours between updating the order in Base and the marketplace or customer actually seeing the tracking number or invoice. For full details on how tracking and invoice forwarding works, see Shipping Labels and Invoices.
Combine webhooks for fast reaction to critical events (such as cancellations) with regular getOrders and getJournalList polling as a safety net. If a webhook fails for any reason, your polling loop will still catch the event and keep your system in sync.
This two-layer strategy gives you both speed and resilience without relying on a single point of failure.