What authentication does the Payload CMS API use?

Payload CMS supports two authentication methods: JWT bearer tokens passed in the Authorization header, and HTTP-only cookies named payload-token set during login. Both are obtained from the POST /{collection}/login endpoint. Through Jentic, JWT tokens are managed automatically in your Jentic One instance.

Can I query documents with filters using the Payload CMS API?

Yes. The GET /{collection} endpoint supports query parameters for filtering by any field, sorting, pagination with limit and page parameters, and depth control for relationship population. Query operators include equals, not_equals, greater_than, less_than, like, contains, and exists.

Does the Payload CMS API work with any collection type?

Yes. The API uses a generic pattern where {collection} in the URL maps to any collection slug defined in your Payload configuration. Whether you have posts, products, users, or custom types, the same endpoints apply. The response schema adapts to the fields defined in each collection.

How do I create content in Payload CMS through Jentic?

Search Jentic for 'create a document in a CMS collection' to find the POST /{collection} operation. Jentic returns the input schema showing the collection path parameter and the document body fields. Provide your collection slug and document data, and Jentic handles authentication and request execution. Install with pip install jentic.

Can I manage global settings through the API?

Yes. The GET /globals/{global_slug} endpoint retrieves any global configuration defined in your Payload project, such as site settings, navigation menus, or footer content. You can update globals with a PATCH request to the same endpoint. Globals are singleton objects that exist outside of collections.

Can I limit what my agent is allowed to do with the Payload CMS API?

Yes. Because Jentic One is self-hosted and runs under your own rules, you decide which Payload operations and which stored token your agent may use. Payload places the collection and document id in the URL path (/{collection}/{id}), so a rule can pin the agent to reading a single collection, letting it fetch and list those documents and nothing else. Update and delete operations stay out of reach unless you explicitly add them, so the agent never writes to or removes content you did not grant.