Integrations
CityScreen Deals connects to several external systems out of the box, each with its own settings section and its own failure log. Programs that sign in to CityScreen Deals, or sign employees in through it, are listed under Identity and API access. Anything beyond these lists is connected through the REST API or the process engine — see Connecting a system that is not on this list.
Available integrations
| Integration | Direction | Purpose |
|---|---|---|
Inbound and outbound |
Pulls digital display inventory from CS Play; pushes booked campaigns back as live playback content. |
|
Outbound |
Feeds display data, prices, and free periods to the programmatic marketplace so that reserved or booked inventory is removed from programmatic sale. |
|
Inbound |
An embeddable widget that lets website visitors browse inventory and submit booking requests, which arrive as inquiry deals. |
|
Inbound |
Imports customer master data from SAP C4C so that sales works with the same customer records as the finance system. |
|
Outbound, with status polling |
Submits invoices for e-invoicing validation through ClearTax, polls for government approval, and downloads QR codes. |
|
Outbound |
Posts approved invoices into the CODA ledger as accounting transactions, so finance works from the invoice sales approved. |
|
Inbound and outbound, from business processes |
Lets script tasks read records from a 1C base and create or change records in it over the standard OData interface, with every request in the organization’s journal. |
Identity and API access
The functions below let other programs call CityScreen Deals, sign employees in through it, or read its directory. Each is configured on its own screen. These functions are licensed. If your organization’s license does not include them, contact CityScreen.
| Function | Used by | Purpose |
|---|---|---|
Your own systems, and applications an employee allows |
Registers an application that obtains access tokens from CityScreen Deals: a service account with roles of its own, or access to the REST API on behalf of an employee who allowed it. |
|
Your other web applications |
Lets an employee sign in to a wiki, a dashboard or another application with the CityScreen Deals account, passes the employee’s groups, and tells the application when the employee signs out. |
|
Mail servers and other systems |
Publishes employees and employee groups as a read-only directory over LDAPS, and checks passwords for the systems that sign people in. |
|
An employee’s scripts and local tools |
A token that calls the REST API with the employee’s own access. |
Employees create their personal access tokens, and the app passwords for their mail clients, under Account. See Access Tokens and App Passwords.
Where settings live
Integration credentials and switches are configured in Settings → Sync (labelled "Synchronization settings" in the permission model). Each integration has its own section on the Sync page — CMS integration, SSP integration, C4C integration, and ClearTax integration.
The booking widget is configured separately, in Settings → General → Inventory booking widget.
Both areas are governed by the same permission: the Synchronization settings bucket. A role that can edit one can edit the other. See Roles & Permissions for details.
CityScreen records the connection to Unit4 CODA for your organization.
Connection accounts of 1C:Enterprise bases are kept in Settings → 1C and are governed by the Organization settings permission.
When an outbound push fails
When an outbound push fails — a campaign export to CS Play, a feed to CityScreen Context, or an invoice submission to ClearTax — the failure is recorded and the exchange stops. It continues when someone runs the push again, or when the next scheduled run comes for an integration that has one. Troubleshooting Sync lists where each integration’s failure log lives and how to run it again.
Connecting a system that is not on this list
The integrations above ship with the product. Anything else — an accounting system, an ERP, a regional tax authority, a client’s own reporting endpoint — is connected through the REST API or through the process engine.
There are three routes. With the REST API the other system starts the exchange and calls CityScreen Deals. A script task and a backend extension run inside a business process, which calls out. The difference between those two is who writes the code.
- REST API
-
Your own system signs in with an OAuth application, which is a service account with roles of its own, or with a personal access token when an employee’s script does the calling. It acts with the permissions that credential carries. This needs no involvement from us once your license includes the functions. It suits a system that starts the exchange itself, such as one that pushes a record in or reads a list.
- Script task
-
A step in a business process that runs JavaScript you write yourself in the process designer. It can read and write process variables and call out over HTTP. This needs no involvement from us: an administrator with access to the process designer can build and change it. It suits straightforward exchanges such as posting a payload, fetching a value or reshaping data between steps.
See Script Tasks.
- Backend extension
-
A component that CityScreen develops for your organization and that a process calls as a service task. This is the route for exchanges a script cannot carry: proprietary protocols, credentials that must never reach a script, large payloads, or anything needing retry and transactional behavior.
See Service Tasks for how a process calls one.
| Backend extensions are bespoke development, commissioned per customer. Talk to us about what you need connected and we will scope it. |
A script task and a backend extension both live inside a business process, which means they inherit that machinery: they run where you place them in the flow, and when one fails it raises an incident on the process instance.