Table of Contents


1. 200ok alephDAM

This is the service documentation for the 200ok Gmbh product alephDAM. It is intended for developers and system administrators working with alephDAM.

alephDAM allows you to integrate news from content providers into your site. You can automatically deliver tens of thousands of articles, videos, and images every day - based on rules that you configure. Manage your assets with a single point of integration and configuration instead of dealing with many vendors.

alephDAM seamlessly integrates into your existing workflows. It works with your CMS, ePaper, print, and archive systems.

For more general information see, read our PDF document brief description (German) or schedule a demo by writing to

1.1. Feedback

Please let us know about gaps or errors in our documentation at

1.2. High level architecture diagram

Let's begin with the 50'000ft view of alephDAM. It's a good entry point into understanding the basic concepts.


2. API

For ingesting data, alephDAM offers three protocols:

2.1. FTP

FTP is the industry standard to ingest news. Even though FTP is rather old technology, our FTP servers are not just robust, but also modern and event oriented. As a customer, you can just upload your data via FTP and leave the rest to alephDAM - your data will be processed within milliseconds.

2.2. S3

You can upload your data to an AWS S3 bucket. Your data will be processed in an event oriented manner using AWS SNS.


alephDAM has an original HTTP REST API. It is documented with the industry standard OpenAPI Swagger - a sample instance is available at .

Here is an overview of the resources that can be managed via the HTTP REST API:


2.3.1. Example requests

  1. Documents

    These two endpoints are relevant for managing documents:

    • Creating new documents: POST /api/v1/{tenant}/documents
    • Getting information on a document: GET /api/v1/{tenant}/documents/{uuid}

    Let's first create a new document which should resemble a video. It optionally takes misc metadata. The absolute minimum to ingest a new video are:

    • source_url: HTTP accessible URL from where alephDAM can download an asset.
    • type: Everything ingested in alephDAM is a 'document'. In the case of creating a video document, the type would be "video".
    • identifiers: The 'identifiers' from the upstream document. The type of these identifiers will vary across agencies, products and types. The first identifier will be used to identify documents and subsequent updates of the same document. It serves as a foreign key.
    • title: The 'title' of the upstream document.

    Setting a poster image is technically not necessary, but a common use case:

    • images: A list of attached images for the video. The first one will be used as a poster image.

    There are a lot more options for setting metadata. For ease of use, we'll be doing a minimal example here. For more information on the available metadata, please see .

    Here's what the request would look like using the popular httpie cli tool:

    http --ignore-stdin --pretty format \
         ''${auth_token} \
         identifiers:='["some_key_123"]' \
         title="Demo Video with poster image" \
         type="video" \
         language="en" \
         images:='[{"url": ""}]' \
        "identifiers": [
        "images": [
    	    "url": ""
        "language": "en",
        "observed-datetime": "2022-08-23T08:01:35.708Z",
        "source-url": "",
        "title": "Demo Video with poster image",
        "type": "video",
        "user": "lsi",
        "uuid": "563a120d-fe55-4ff2-bfde-f5da86f4e01d",
        "workflow": "process.lsi.application.json"

    Here's what such a request would look like in Swagger:


    Now you have created a document in alephDAM and received a response with minimal information to later make queries on any updates regarding the document.

    The document will now be processed in the background. To make further inquiries on the document, you can make subsequent requests. For that, you can use the unique identifier of the document, the uuid.

    Here's how to receive information on this document, including the video URL and ID on Brightcove:

    http --ignore-stdin --pretty format \
        "agency": "lsi",
        "asset-size": null,
        "author": null,
        "bc-backlink": "",
        "bc-id": "6305980805112",
        "catchline": null,
        "categories": null,
        "complete": true,
        "created-at": "2022-05-12T09:33:09.889Z",
        "errors": [],
        "exported": null,
        "genres": null,
        "id": 3496049,
        "identifiers": [
        "images": [],
        "keywords": null,
        "language": "de",
        "li-backlink": null,
        "locale": "de",
        "locations": null,
        "product": null,
        "published-datetime": null,
        "ready": true,
        "source-url": "",
        "special-rules": null,
        "teaser": null,
        "text": "",
        "title": "Demo Video",
        "type": "video",
        "updated-at": "2022-05-12T09:33:12.180Z",
        "urgency": null,
        "urn": "urn:lsi:video:my_key_321",
        "uuid": "3b3e8307-4a0c-4871-88a1-631df09e5154",
        "version": null,
        "video-state": null,
        "workflow": "process.lsi.application.json"

    Here's what such a request would look like in Swagger:


    If there is any error on uploading the video to Brightcove, extensive information will be added to the error field. For example:

    "errors": [
        "type": "export-video-to-bc",
        "message": "Create video request failed",
        "cause": "Reference id urn:lsi:video:1234 is already in use."

Author: 200ok GmbH

Created: 2022-08-23 Tue 11:08