What to Expect in Your Sandbox Log Review

This guide explains what we evaluate during a sandbox API log review and what you should have in place before submitting for review.

Our goal is to identify inefficiencies that could affect your integration's performance or reliability in production, for both your system and ours.

What we evaluate

Webhooks

If your integration uses webhooks, we verify that the relevant types are enabled and being successfully delivered to your system.

We look for evidence that your system is consuming webhook events and responding to them appropriately. For example, performing a GET request on the relevant resource after receiving an update event.

If your integration relies on webhooks and there are failed deliveries with HTTP errors, we'll raise that as an issue.

For guidance, see Webhooks.

Token management

We review how your application handles token issuance and reuse.

Tokens should be requested once and reused for their full valid lifetime. We look for implementations that cache the current token and only request a new one after the existing token has expired. Generating a new token before each API request is considered an inefficiency.

For guidance, see Managing the Authorization Lifecycle.

Polling

We assess whether your application relies on excessive or unnecessary polling.

A common example is fetching user details before every API request. We recommend caching user details locally and refreshing only when a user_updated webhook is received. Patterns like this, if unaddressed, can create unnecessary API load.

Polling is often a sign that webhook events aren't being consumed. GET requests should generally only be happening following a relevant webhook. If lots of polling unrelated to webhooks is present, we'll evaluate whether its frequency and scope are reasonable.

Secure endpoint usage

We verify that your integration is using the correct base URL for each resource.

Most API requests should use the standard sandbox base URL:

https://api-sandbox.astra.finance

The following resources require the secure endpoint and should be called accordingly:

Using the secure endpoint for requests outside of these resources is flagged as an issue. For a full overview of available endpoints, see the API reference.

User intent data

Applies only if personal verified users are part of your flows.

We review user intent data for completeness and accuracy:

• No misplaced values (for example, a first name entered in the street_1 field)

• Values are distinct across unique individuals

• If your integration is not KYC delegated, last 4 SSN and date of birth are required where applicable. These fields are optional for KYC-delegated integrations.

For guidance, see Create a User Intent and User Webhooks Reference.

Anomalous activity

We flag anything that appears unnecessarily repetitive, inefficient, or unexpected.

Review summary

At the close of every review, we summarize our findings and call out anything that should be addressed before production access or go-live. Our aim is to protect both your integration and our infrastructure from issues that would create operational burden down the line.