Every endpoint of the Core dna REST API, with requests to copy in HTTP, cURL, PHP, Python and JavaScript, and the real responses they return. The examples run against this site’s own content.
Every site answers under /cdna-api on its own hostname. Send an OAuth access token, or an API key, as a Bearer token, and ask for the fields you want with properties.
properties, filters and orderBy: The REST API.GET /cdna-api/pages/pages?parent.id=72&orderBy=position:ASC&properties={id,name,fullPath} HTTP/1.1
Host: hub.coredna.com
Authorization: Bearer YOUR_ACCESS_TOKEN
Accept: application/json{
"result": "success",
"totalCount": 2,
"data": [
{
"id": 818,
"name": "API Reference",
"fullPath": "/developer-docs/api-reference"
},
{
"id": 1878,
"name": "Reference",
"fullPath": "/developer-docs/reference"
}
]
}Your first authenticated request, what the placeholders in the examples stand for, and what every response looks like.
How a request proves who sent it. An OAuth access token is the preferred method and an API key the older one; both go in the Authorization header as a Bearer token.
The parameters every endpoint shares, shaping a response with properties, what every response looks like, the status codes, and the failures that still answer 200.
The keys that replace, change, insert, append and remove the elements of a component collection, in one request with the rest of an edit.
One POST endpoint that reads several kinds of record in one request, with only the fields you name. It reads only, and takes a GraphQL-like query rather than full GraphQL.
Blogs, their posts and the comments on posts, read by id or by URL.
Books, their units and pages, and a book’s PDF export.
The records no single module owns: input types, layouts and their categories, categories, global components and tags.
Records of any custom entity type, addressed by the type’s identifier in the path, with their revisions and bulk changes.
FAQ pages, the questions on them and the comments on questions. Pages and questions keep their content in revisions.
Images, and files uploaded into the file manager.
Form definitions and the submissions made to them.
Menus, the named trees of links that templates read, and the elements inside them.
The site’s page tree: list pages, read one by id or by URL, create, edit, roll back, duplicate and delete. A page keeps its content in revisions, so every edit makes a revision, and the request decides whether it goes live.
Content workflows: their steps, the approvals a revision branch collects, and comments on a branch.
Carts and their items, discount codes and messages, open to visitors with no credentials.
A checkout made from a cart: the shopper, the addresses, shipping, discount codes, and the purchase that turns it into an order.
Discount codes: the codes a shopper types to apply a discount made in the admin.
Warehouses, stock levels and the inventory transactions that record each movement.
Payment methods, invoices, their transactions, and the refund calculator.
Orders: what a paid checkout becomes, and orders an integration records directly.
Products: their SKU, prices per currency, categories and publishing. Descriptions, variants and categories have pages of their own.
Quotes: priced offers made to a customer, which they accept and pay.
Tax categories, which decide how a product is taxed.
The site’s configuration settings, read one key at a time or all together.
Jobs, formerly hooks, in the Orchestration module: their categories, actions, conditions, triggers and runs, and the web-event URL that starts a job. The routes keep the old name, /cdna-api/hooks/.
Email batches and the emails sent in them.
URL rewrite and redirect rules.
Scheduler tasks: background work that runs on a cron interval, or once at a set time.
Running a search view from code: full-text queries, filters, sorting, highlighting and facets.
Sites, and site data: a store of keys and values that templates read as $_siteData.
The signed-in account, users, people, address types, authors, groups and permissions.