Regions and data residency

#Available regions

Tend operates in four regions. Each region is a self-contained deployment with its own scheduler, queue storage, and webhook delivery workers. A job created in one region is stored, scheduled, and executed in that region. It is not replicated elsewhere unless you pin work to multiple regions yourself.

Hobby projects run in us-east only. The base URL is the same for every region: https://api.tendcomputer.com/v2. You select a region with the region field on the resource, not by changing hostnames.

#Choosing a region

Two considerations matter: latency and residency. For latency, choose the region closest to the endpoints your jobs call. Tend delivers your job to your handler over HTTPS, and a 15-second webhook timeout is easier to meet when the round trip is 20 milliseconds instead of 250. For residency, choose the region that satisfies your contractual or regulatory obligations, described in the next section.

If you omit region, the job is routed to your project's default region. New projects default to us-east. You can change the project default in the dashboard; the change applies to jobs created afterward and never moves existing jobs.

• Handlers in Virginia or the northeastern US: us-east.
• Handlers on the US West Coast: us-west.
• Handlers in the EU, or data subject to EU residency expectations: eu-central.
• Handlers in Southeast Asia, Australia, or India-adjacent networks: ap-southeast.

#Pinning jobs to a region

Set region on a job or schedule to pin it. Pinning is permanent for that resource: a job's region cannot be edited after creation, because doing so would mean moving stored payloads and run history between regions. To change region, create a new resource and delete the old one.

curl -X POST https://api.tendcomputer.com/v2/jobs \
  -H "Authorization: Bearer $TEND_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "region": "eu-central",
    "run_at": "2026-06-10T07:30:00Z",
    "target": "https://api.brauhaus-orders.dev/hooks/invoice",
    "payload": {"order_id": "ord_88231"}
  }'

job = client.jobs.create(
    region="eu-central",
    run_at="2026-06-10T07:30:00Z",
    target="https://api.brauhaus-orders.dev/hooks/invoice",
    payload={"order_id": "ord_88231"},
)
print(job.id, job.region)  # job_01J9A3VD8H4F6PQ2S7YTGN1XKB eu-central

const job = await client.jobs.create({
  region: "eu-central",
  runAt: "2026-06-10T07:30:00Z",
  target: "https://api.brauhaus-orders.dev/hooks/invoice",
  payload: { orderId: "ord_88231" },
});
console.log(job.id, job.region);

job, err := client.Jobs.Create(ctx, &tend.JobParams{
	Region: "eu-central",
	RunAt:  "2026-06-10T07:30:00Z",
	Target: "https://api.brauhaus-orders.dev/hooks/invoice",
	Payload: map[string]any{"order_id": "ord_88231"},
})
if err != nil {
	log.Fatal(err)
}
fmt.Println(job.ID, job.Region)

#What stays in the region

For a job pinned to a region, the following data is stored only in that region: the job definition, the payload, run history and logs, retry state, and delivery attempts including response bodies captured for debugging. Scheduling and execution happen in that region's workers, and outbound webhook deliveries originate from that region's egress addresses.

Some data is global by necessity. Account and billing records, team membership, API key hashes, and aggregate usage counters used for invoicing live in our primary account systems, which are operated from the United States. These records contain no job payloads. If your compliance program needs details on this split, Enterprise customers receive a data-flow document as part of the annual security review, along with custom data-processing terms.

#Listing and querying across regions

List endpoints return resources from all regions your project uses, each tagged with its region. Pass region as a query parameter to filter. Pagination is cursor-based: pass limit (default 50, maximum 200) and the cursor value returned in the previous response's next_cursor field.

curl "https://api.tendcomputer.com/v2/jobs?region=eu-central&limit=100" \
  -H "Authorization: Bearer $TEND_API_KEY"

for job in client.jobs.list(region="eu-central", limit=100):
    print(job.id, job.region, job.status)

for await (const job of client.jobs.list({ region: "eu-central", limit: 100 })) {
  console.log(job.id, job.region, job.status);
}

#Regional unavailability

When a region cannot accept new jobs, the API returns 503 region_unavailable for requests that name that region. Already-accepted jobs are durable and resume when the region recovers; a brief outage delays runs but does not lose them. Treat the 503 as retryable with backoff.

If residency permits, you may omit region to route to your default instead. If it does not, retry against the same region. Tend never silently reroutes a pinned job to a different region, because that would violate the residency guarantee you asked for.

{
  "error": {
    "code": "region_unavailable",
    "message": "Region eu-central is temporarily unable to accept new jobs.",
    "request_id": "req_01J9B7M2RX5D8KQ4W0ZHPSTN3E"
  }
}