Introduction

#What Tend does

Tend is a hosted developer API for scheduling and running background jobs. You describe work ("call this URL with this payload at 02:00 every night" or "deliver this message in 45 minutes") and Tend takes responsibility for firing it on time, retrying it when it fails, and telling you what happened. You do not run a queue, a scheduler process, a Redis instance, or a cron daemon that someone will forget to restart.

The feature set is deliberately small. Tend supports cron schedules, delayed one-off jobs, automatic retries with backoff, per-project concurrency limits, and signed webhook deliveries of job results. It does not run your code. Your code stays where it is, behind an HTTPS endpoint you control, and Tend calls it. This keeps the product simple and keeps your runtime, dependencies and secrets out of our hands.

• Cron schedules fire recurring jobs on a cron expression in any IANA timezone, no more often than once every 30 seconds.
• Delayed jobs run exactly once at a run_at time you choose, or after a delay_seconds offset.
• Retries are automatic. Each job gets 5 attempts by default and up to 25 if you ask, with exponential backoff and full jitter.
• Concurrency limits cap how many runs execute at once, so a burst of 10,000 jobs does not flatten your database.
• Signed webhooks deliver results to your endpoint with a Tend-Signature header you can verify.

#How a job executes

Every job follows the same path. You create it through the REST API or an SDK. Tend stores it durably, then waits until it is due. When the job is due, Tend makes an HTTPS request to the target URL with your payload, records the response, and decides whether the attempt succeeded. A 2xx response within the timeout is a success. Anything else is a failed attempt and, if attempts remain, is scheduled for retry.

create job --> stored --> due --> attempt 1 --> 2xx? --> succeeded
                                        |
                                        v no
                                  wait (backoff + jitter)
                                        |
                                        v
                                    attempt 2 ... attempt N --> failed

A single job can produce several runs (one per scheduled firing) and each run can contain several attempts. The Core concepts page covers this hierarchy in detail. For now, the useful mental model is: jobs are what you define, runs are what happens, and webhooks are how you hear about it.

#Your first request

The API lives at https://api.tendcomputer.com/v2 and the current API version is 2026-03-01. Authentication is a bearer token in the Authorization header. The quickest way to confirm your key works is to list your jobs, which on a new project returns an empty page.

curl https://api.tendcomputer.com/v2/jobs \
  -H "Authorization: Bearer tnd_dev_8fQ2mLx0aVt3"

from tend import Tend

client = Tend(api_key="tnd_dev_8fQ2mLx0aVt3")
for job in client.jobs.list(limit=10):
    print(job.id, job.status)

import { Tend } from "@tend/sdk";

const client = new Tend({ apiKey: "tnd_dev_8fQ2mLx0aVt3" });
const page = await client.jobs.list({ limit: 10 });
console.log(page.data.length, page.next_cursor);

package main

import (
	"context"
	"fmt"

	"github.com/tendcomputer/tend-go"
)

func main() {
	client := tend.NewClient("tnd_dev_8fQ2mLx0aVt3")
	page, err := client.Jobs.List(context.Background(), &tend.ListParams{Limit: 10})
	if err != nil {
		panic(err)
	}
	fmt.Println(len(page.Data), page.NextCursor)
}

An empty response looks like this. If you see data as an empty array and next_cursor as null, you are connected and there is simply nothing there yet.

{
  "data": [],
  "next_cursor": null
}

#Regions and limits

Tend runs in four regions. Jobs route to us-east unless you specify otherwise. Pro and Scale projects can pick any region, and Scale projects can pin individual jobs to a region. Hobby projects run in us-east only.

A few hard limits apply to every plan. A job payload can be at most 256 KB after JSON encoding. A single run may execute for at most 15 minutes. Cron schedules cannot fire more often than once every 30 seconds. Exceeding these limits returns a specific error code (payload_too_large, interval_too_short) rather than a vague failure, because we would prefer you find out at creation time instead of at 3 a.m.

#Official SDKs

The REST API is the source of truth and everything here works with plain HTTP. The official SDKs add typed models, automatic pagination, retry handling for transient API errors, and webhook signature verification helpers.

All three SDKs pin to API version 2026-03-01 by default, so upgrading an SDK does not silently change API behavior unless the release notes say so.

#Where to go next

• Quickstart creates a delayed job and a cron schedule in about ten minutes.
• Authentication and API keys explains key prefixes, environments and safe storage.
• Core concepts defines jobs, schedules, runs and attempts precisely, including the retry math.