Two environments, one API

Beeswax STP has two distinct environments:

Environment ATO gateway Token prefix Employer environment Purpose
Test EVTE (ATO test gateway) stp_test_... evte Development, CI, staging, load testing
Live ATO production stp_live_... production Real lodgements that count for compliance

Both environments share the same base URL: https://stp.beeswaxapp.com/api/v1/. The environment is determined by the token you authenticate with — not by the URL.

What this means in practice

  • A test token can only see and modify employers where environment = "evte". Attempting to read a production employer via a test token returns a 404 as if it didn't exist.
  • A live token can only see and modify employers where environment = "production". Same strict isolation in the other direction.
  • Data is completely separate. Test employers, test employees, test pay events, test submissions — none of them are visible to live tokens, and vice versa.
  • YTD accumulation is tracked independently per environment, so your EVTE test data never contaminates your real financial year totals.

Why not use separate URLs?

Different URLs for test and sandbox mean two DNS records, two TLS certs, and more things to configure. Using a single URL with token-based environment detection keeps your integration simple:

  • One base URL to configure
  • One set of client code
  • Switch environments by switching tokens (e.g. environment variable)

Creating an employer in each environment

When you create an employer, pass the environment field explicitly:

# Test / EVTE
curl https://stp.beeswaxapp.com/api/v1/employers \
  -X POST \
  -H "Authorization: Bearer stp_test_..." \
  -H "Content-Type: application/json" \
  -d '{ "employer": { ..., "environment": "evte" } }'

# Live / production
curl https://stp.beeswaxapp.com/api/v1/employers \
  -X POST \
  -H "Authorization: Bearer stp_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "employer": { ..., "environment": "production" } }'

Creating an employer with an environment that doesn't match the token's environment is a no-op — the employer still gets created, but it will be invisible to your token and only accessible through the web UI or a matching token.

EVTE (sandbox) specifics

EVTE is the ATO's test environment. Submissions to EVTE:

  • Are validated against the same PAYEVNT.0004 schema as production
  • Do not count for compliance purposes
  • Do not appear in the real employer's ATO records
  • Are usually processed within seconds (much faster than production, which can take minutes)
  • Can be submitted at any volume — useful for load testing your integration

EVTE uses Beeswax STP's shared test credentials, so you don't need to set up your own ATO M2M credentials to start testing. This is unique to the test environment — live submissions require your own credentials.

Going from test to live

When you're ready to ship real lodgements:

  1. Verify your integration in EVTE first. Create employers, employees, pay events, and submit. Make sure every happy and unhappy path works.
  2. Set up your ATO M2M credentials for the live ABN. This is where you upload your keystore file and software ID to Beeswax STP under Settings → STP Configuration.
  3. Create a live API token (stp_live_...) with the scopes you need.
  4. Create a live employer (environment: "production") using the live token.
  5. Test with a dummy pay event — a single employee, $0 amounts, to confirm the full round-trip to the ATO production gateway. You'll see an accepted submission come back.
  6. Swap your production config to use the live token.

At no point do you need to change URLs or code paths — just rotate the token and the environment flag on new employer records.

Rate limits differ by environment

Test tokens get a more generous rate limit (600 req/min) than live tokens (120 req/min). This is so you can hammer your integration under load without needing a separate high-throughput plan. See Rate limits.

Webhooks are environment-scoped too

Webhook endpoints are created with an environment field of test or live. Events from an EVTE submission are only sent to test endpoints; events from a production submission are only sent to live endpoints. This prevents test traffic from waking up your production monitoring. See Webhooks.

Troubleshooting

"I created an employer but I can't see it"
The most common cause is an environment mismatch. Check that the token you're querying with matches the employer's environment field. Use the web UI (which shows both environments) to verify the employer exists.

"My test token accepts an ATO submission, but my live token doesn't"
The test environment (EVTE) is typically much more permissive and faster than production. Real submissions can fail for reasons that EVTE accepts — most commonly around credential validation and ABN / BMS ID mismatch. Always read the actual error response from the ATO, available on the submission detail endpoint.

"I need to copy data from test to live"
You can't. The environments are intentionally isolated — data flow between them would defeat the purpose. For CI fixtures, script the creation of your test data via the API.