Agiled Docs
Developers

Test the API Locally

Test API requests from a local script or terminal.

Use local scripts to verify authentication, request bodies, pagination, and webhook receivers before connecting production systems.

Environment Variables

export AGILED_API_BASE_URL="https://your-api-origin.example"
export AGILED_API_TOKEN="paste-token-here"

Smoke Test Authentication

curl "$AGILED_API_BASE_URL/public/v1/me" \
  -H "Authorization: Bearer $AGILED_API_TOKEN"

Run this before testing writes. If /me fails, fix the base URL, token, or environment before debugging request bodies.

Test a List Endpoint

curl "$AGILED_API_BASE_URL/public/v1/contacts?per_page=5" \
  -H "Authorization: Bearer $AGILED_API_TOKEN"

Test a Write Endpoint

Use a safe test record and an idempotency key:

curl "$AGILED_API_BASE_URL/public/v1/contacts" \
  -X POST \
  -H "Authorization: Bearer $AGILED_API_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: local-test-contact-1" \
  -d '{"first_name":"Local","last_name":"Test","email":"local.test@example.com"}'

After the write succeeds, open Agiled and verify the created record. Then repeat the same request with the same idempotency key to confirm retries do not create duplicates.

Keep Local Tests Safe

Use test customers, obvious names, and limited scopes. Do not run local scripts against production data until you have tested pagination, idempotency, validation errors, and rollback or cleanup steps.

Local Test Sequence

Use the same sequence for every new integration:

  1. Call /public/v1/me.
  2. List a small page from the target resource.
  3. Create one obvious test record with an idempotency key.
  4. Repeat the same write request and confirm it does not duplicate.
  5. Open Agiled and verify the created record.
  6. Delete, archive, or label test records according to your cleanup process.

This catches base URL, token, request body, and retry problems before a script touches real customer or finance data.

Keep Test Data Obvious

Use names, emails, invoice numbers, and project titles that clearly identify the record as a local API test. Avoid realistic customer names that could be mistaken for live work.

After testing, either delete the records or keep them in a known test workspace. Do not leave test invoices, contacts, or tasks in production reports.

On this page