# What can your own programs do with Szenera?

Everything the portal can do. The interface calls no secret special routes. It uses the same API that is open to you, with a key instead of a sign-in.

> **Type:** concept
> **For:** Technically skilled teams who connect Szenera to their own systems, and anyone who issues access for them.
> **Prerequisite:** The permission **List API keys** or **Create API keys** for API keys, and **List webhooks** for webhooks. Both areas belong to the Premium package.
> **Where in the portal:** **Settings › Organization › API keys** and **Settings › Organization › Webhooks**

## Seven ways

The API is the main way: 395 operations on 310 paths, JSON in both directions, standard methods, and standard status codes. Every route is described in an OpenAPI 3.1 specification that is generated from the source code and therefore never goes stale. Generate a client in your own language from it instead of typing addresses by hand. Lists respond with `items`, `total`, and `nextCursor`: pass the cursor back on the next call. If it is missing, that was the last page.

The `szenera` command line is the same way, only typed. It is built for processes and usable by people: at a terminal you get a table, in a script you get JSON, and the exit codes separate the kinds of error, so a script can react without comparing text.

Webhooks reverse the direction. Instead of asking at intervals, you register an address and the events you care about. Szenera delivers, signs every delivery, and keeps a delivery log that you can inspect. Event names already carry area, subject, and action: `composition.scene.published` tells you what happened without a lookup.

The Apps SDK is the fourth way. With it you do not build a program next to Szenera but an app of your own that appears in the store, shows up in the scene editor, and runs on the display.

![Four ways between your systems and Szenera: a program and a script call the API, events are delivered to your receiver, an app of your own goes into the catalog](/docs/developers/bilder/0ef20996-integration-paths.svg)

_The drawing shows the four ways in which you build something yourself. Three more need no build of your own. In their case, a third-party program already brings what it needs._

**Connected applications** are the fifth way. A third-party program, such as a command-line tool or an application on your computer, asks your permission once, and from then on it acts in your name, with exactly the permissions you gave it. It never receives your password, and you take the permission back with one click: [Allow and revoke connected applications](/docs/organization/connected-applications).

**AI assistants** are the sixth. You enter an address from Szenera and sign in with your account, and the assistant can look at your inventory and make suggestions. It asks before anything lands on a display. It cannot delete anything. The mechanism behind it is the same as for a connected application.

**Accounts from your employee directory** are the seventh. If your organization runs a directory, it creates the accounts here, suspends them when someone leaves, and sets the roles, so nobody has to maintain both: [Accounts from your employee directory (SCIM)](/docs/organization/scim-provisioning).

## What happens in the portal and what lies outside it

In the portal you do exactly two things: you issue **API keys** and you create **Webhook endpoints**. Both sit in the **Organization** tab of the settings, both depend on a permission of their own, and both belong to the Premium package. Existing keys and endpoints keep working even if the package changes later. You can revoke, switch off, and delete them at any time anyway.

A key replaces the sign-in, not the permission check. You choose its permissions for each key, and nothing is inherited. It can never do more than you can yourself. The portal says so at the **Permissions** field.

Two of the newer ways also have a portal page, but no button to create anything: A **connected application** is created in the application itself and afterwards appears under **Settings › My account › Security**. **Provisioning** is switched on under **Settings › Organization › Company sign-in** and first needs an active sign-in method through the company account.

Everything else is not a portal task and is therefore not covered here but at `https://developer.szenera.com`: the reference for every single route, the complete list of error codes with the expected reaction, idempotency, verifying signatures, the commands of the command line, the Apps SDK, the tools for assistants, and the changes per version.

## What follows

Check the permission and the package first, then issue the key. A key you create without the necessary permissions is not a smaller key but one that is rejected on its first call.

And give each key only what its purpose needs. An import that uploads media does not need to be allowed to change schedules. The six classes in the create dialog exist for exactly this.

## Related

- [Create, rotate, and revoke an API key](/docs/developers/create-api-key)
- [Set up webhooks and check deliveries](/docs/developers/set-up-webhooks)
- [The szenera command line](/docs/developers/command-line)
- [Allow and revoke connected applications](/docs/organization/connected-applications)
- [Accounts from your employee directory (SCIM)](/docs/organization/scim-provisioning)
