Core concepts

Anythink turns a data model into a backend. You describe your data once, as entities and fields, and your project gives you a REST API, sign-in, access control, file storage, search, workflows and dashboards that all work from that model. This page names each idea and shows how they connect, so the rest of the docs read easily.

How it fits together

text

Project
  |-- Entities (orders, customers, ...)
  |     |-- Fields (name, price, customer -> customers, ...)
  |     |-- Records (the rows you store)
  |     '-- Instant REST API  /org/{project_id}/entities/{entity}/items
  |-- Users, roles, permissions, API keys, row-level security
  |-- Files, search, workflows, payments, dashboards
  '-- Driven from: the Anythink dashboard, the CLI, or MCP

Everything below lives inside one project.

Project

A project is your whole backend: its data model, records, users, files, workflows and settings. Projects are isolated from each other, so a staging project and a production project never share data. Every API URL contains the project's id, written {project_id} on this page.

You create projects from the Anythink dashboard or with anythink projects create, and the CLI works against whichever project is active (anythink projects use).

Entities, fields and records

An entity is a type of thing you store, such as products, orders or blog_posts. Each entity has fields, and each field has a type. The things you save are records: one record is one product, one order, one post.

Fields carry the type that decides how a value is stored and validated. The main types are:

Type	Use it for
`varchar`, `text`	Short and long text
`integer`, `bigint`, `decimal`	Whole numbers and decimals
`boolean`	True or false
`date`, `timestamp`	Dates, and dates with a time
`jsonb`	Structured data of any shape
`geo`	A location
`file`	A file stored in the project
`user`	A link to a user
Array types such as `varchar[]`	A list of values

A field can also be required or unique, and can have a default value.

Relationships are fields. A field of type many-to-one on orders that points at customers is how an order belongs to a customer. The other relationship types are one-to-one, one-to-many and many-to-many. You don't create a separate join object: the relationship is just another field, and the API treats it like one.

bash

anythink entities list
anythink fields add orders total --type decimal --required

See Model your data for the full walkthrough, Data Types for every type and Connect entities with relationships for relationships.

The instant REST API

When you save an entity, its REST API exists. There is nothing to deploy and no routes to write. Each entity gets the same endpoints:

http

GET    https://api.my.anythink.cloud/org/{project_id}/entities/{entity}/items
GET    https://api.my.anythink.cloud/org/{project_id}/entities/{entity}/items/{id}
POST   https://api.my.anythink.cloud/org/{project_id}/entities/{entity}/items
PUT    https://api.my.anythink.cloud/org/{project_id}/entities/{entity}/items/{id}
DELETE https://api.my.anythink.cloud/org/{project_id}/entities/{entity}/items/{id}

The list endpoint is paginated with page and pageSize and can sort and filter. Add a field and the endpoint accepts it straight away, which is why the usual loop is: change the model, call the API, build against it.

The API is REST over HTTP and JSON. Call the instant REST API covers requests, pagination, filtering and sorting.

Authentication and access

Every request to your project is authenticated as either a user or an API key.

	Users and sessions	API keys
For	The people using your app	Servers, scripts and CI you run yourself
How it works	A user signs in and receives an access token	You create a key with a chosen list of permissions
Sent as	`Authorization: Bearer <token>`	`x-api-key: <key>`

Users sign in with email and password, or with a social provider, and the SDK keeps their session alive. See Sign in users, Anythink SDK: sign-in and sessions and API keys.

Once a request is authenticated, three layers decide what it can do:

Roles and permissions. Each user has a role, and a role is a set of permissions. Entity permissions are named {entity}:{action}, for example orders:read, orders:create, orders:update and orders:delete. A request to an endpoint needs the matching permission or it gets 403. Roles can also restrict which fields a user sees. See Control access: roles, permissions and field-level security.
Row-level security. Turn it on for an entity and users reach only the records granted to them, by name or through a group. Two users with the same role can then see different records. See Groups and row-level security.
API key scope. A key holds only the permissions you gave it, and never more than its creator has.

Files, search and workflows

Files. Upload images, documents and video to the project and attach them to records through file fields. See Upload and manage files.

Search. Records in your entities can be searched with full-text search from one endpoint, and anythink search similar finds records like a given record. See Search records across your entities.

Workflows. A workflow runs steps in the background when something happens. It starts from a trigger: an event such as a record or payment change, a schedule (timed), a manual run, or an HTTP call to an API route. It then runs steps: create or update records, send email, call another API, and more. Steps pass data to each other with {{ ... }} template expressions. See How workflows work, Triggers and scheduling and Step types.

Payments and dashboards

Payments. AnythinkPay connects your project to Stripe and verifies Apple in-app purchases. It keeps plans, subscriptions and payment records in your project and raises events your workflows can react to. See How payments and subscriptions work.

Dashboards. Build charts from your entities' data and arrange them on dashboards in the Anythink dashboard, with no separate analytics tool to feed.

Three ways to drive everything

You can do the same things three ways, and they work on the same project, so you can mix them freely. Task pages in these docs show all three.

The Anythink dashboard. A web interface for modelling data, editing records, managing users and permissions, building workflows and charts, and browsing the generated API documentation. Start here to see what's possible.
The CLI. anythink has a command for each area, such as entities, fields, data, workflows, users, roles, files, search, api-keys and pay. It suits scripts, CI and repeatable setup. anythink fetch <path> makes an authenticated request to any endpoint, and anythink docs prints the full reference. See Getting Started with the CLI.
MCP. The Anythink MCP server (@anythink-cloud/mcp) lets an AI assistant such as Claude or Cursor run those same CLI commands for you in plain English. See Connect Claude to your backend with MCP.

The dashboard, the CLI and MCP all call the same REST API that your own app uses, so anything one of them can do, your code can do too.

Next steps

Model your data: entities, fields, relationsCreate entities, add typed fields, set required, unique and indexed, and link records with relationships. Every change updates your REST API at once.

Call the instant REST APIEvery entity gets a REST API as soon as you create it. Authenticate, then list, get, create, update and delete records with curl, the CLI or MCP.

Sign in users: email, tokens and API keysRegister and sign in users with email and password, manage sessions with access and refresh tokens, reset passwords, and know when to use an API key.

Roles and permissionsControl who can do what in your project: create roles, grant permissions, assign them to users, and check what a signed-in user can actually do.

How workflows workWorkflows run your backend logic in Anythink. A trigger starts a job, the job follows a chain of steps, and each step can use what came before it.

Install and use the Anythink CLIInstall the Anythink CLI with Homebrew or a binary, sign in, switch projects safely, and find every command group with a key example.