API
User Manual
  • Introduction to API v2
  • Guides
    • Getting started
    • Authorization
    • Delivery Notes Integrations
  • API Reference
    • General
      • Data types
        • Validation
        • Prices
      • Schema
      • Flags
      • ETags
        • ETag examples
      • Filtering
      • Sorting
      • Paging
      • Methods
      • HTTP Status Codes
    • Enums
      • Payment methods
      • Units
      • Order status
  • Entity
    • Attendance
    • Branch
    • Category
    • Cloud
    • Course
    • Customer
    • Customer Account
    • Customer Account Log
    • Daily Menu
    • Daily Menu Product
    • Delivery Note
    • Discount group
    • EET subject
    • Employee
    • Money log
    • Order
    • Order item
    • Product
    • Product Customization
    • Product Ingredient
    • Reservation
    • Stock Packaging
    • Supplier
    • Table
    • Tag
    • Tax (VAT rates)
    • Warehouse
    • Warehouse Branch
  • Others
    • Reports
      • Base Sales Report
    • POS actions
    • Release notes
    • Breaking changes
    • Webhook
    • Third-party libraries
  • Migration
    • Migrating from API v1
    • API v1 Services
      • Branch Service
      • Category Service
      • Customer Service
      • Employee Service
      • OAuth2 Login Service
      • POS action service
      • Product Service
      • Reservation Service
      • Sale Service
      • Stock Service
      • Supplier Service
      • Tableseat Service
      • Tag Service
      • Warehouse Service
Powered by GitBook
On this page
  • Flow description
  • Register your application
  • Setup for testing
  • Setup for production
  • Obtain the Access Token
  • Check the access
  • Uploading Delivery notes
  • Managing Products

Was this helpful?

Export as PDF
  1. Guides

Delivery Notes Integrations

PreviousAuthorizationNextGeneral

Last updated 2 years ago

Was this helpful?

Electronic delivery notes and Remittances are primarily for suppliers to provide their customers with electronic delivery notes and remittances, and easy stock in.

Purpose of this guide is to ease the integration of a supplier's system with the Dotykacka platform. The customers can then benefit from a smooth cooperation between the two systems which will save their time otherwise consumed by updating products and stock quantities in a delivery note manually item-by-item.

Should you have any questions or issues with the integration do not hesitate to ask us via e-mail

Flow description

  1. The supplier prepares the delivery note XML and uploads it via the API2 (steps to setup and invoke the API2 are described in this guide).

  2. When the XML document is uploaded, it will show up in the customer's Warehouse application.

  3. From there, optionally, the customer can alter selling prices and quantities before confirming to stock in the items.

  4. When confirmed, the application will automatically update product prices and quantities of stock items in the customer's warehouse and it will also set the delivery note status to Stacked.

Register your application

  • Fill in the .

  • We will provide you a Client ID and Client Secret, and a testing license key.

Setup for testing

The steps in this section are very simplified to help you to experiment with the API as quickly as possible but should not be used in production.

  • For testing, create a new Dotypos Account with the provided testing license key.

    (install Dotykacka Application and Activate your license - more info in the )

  • Prepare the connector URL (replace variables {} with client ID and secret):

    https://admin.dotykacka.cz/client/connect?client_id={client_id}&client_secret={client_secret}&scope=*&redirect_uri=https://dotykacka.cz

  • Open the URL in a browser and grant access to your testing cloud.

  • Note down the Refresh Token returned in the URL after you get redirected to dotykacka.cz

    (redirect URL: https://dotykacka.cz?token={RefreshToken}&cloudid={cloudId})

Setup for production

Here are some hints to make your application better prepared for the production.

  • Your application should generate the connector URL query parameters and use the full URL to redirect users automatically.

  • The redirect_uri in the connector URL should be an URL of your webhook that will process the response.

  • The Refresh Token should be stored safely in your application (never expires).

Obtain the Access Token

  • send API request POST https://test.api.dotykacka.cz/v2/signin/token

    • with header: Authorization: User {RefreshToken}

    • and header: Content-Type: application/json

    • and JSON body: { "_cloudId": {cloudId} }

  • parse the response body (JSON) so as to get the value for the key "accessToken"

The Access Token...

  • is valid for a limited time only and when it expires, it must be renewed via this endpoint again.

  • allows access only to the Cloud ID specified in the body of the request that returned it.

  • must be specified when calling any other API v2 endpoint in the headers:

    Authorization: Bearer {AccessToken}

Check the access

During the development stage of your integration code you can call the following endpoint to check you have the right access token with access to the given cloud:

GET https://api.dotykacka.cz/v2/clouds/{cloudId}

Do not forget to add the request header Authorization: Bearer {AccessToken}

If it responds with http status 200 and a cloud info in the body, then you are prepared and ready to call other endpoints.

It is not needed to check the access in production code so we recommend skipping this step for a better performance of your integration code.

Uploading Delivery notes

You can upload a delivery note in a XML format by using the API call.

Call: POST /v2/clouds/{cloudId}/branches/{branchId}/delivery-note-uploads

In case the XML file is not accepted, please make sure it is valid according to the XSD.

Managing Products

You can manage, filter and sort products by using the API calls.

When updating multiple entities, keep the same order in the PUT request as it was in the GET response that returned the ETag.

For endpoints working with a list of entities (POST/PUT), the order of entities in the response is the same as it was sent in the request .

The POST method does not expect an ID so it always creates new products.

The PUT method requires an ID so you need to generate one when you want to create a product using the PUT method.

The JSON samples labeled "Body request minimum" under the POST and PUT requests show the minimum set of fields that are required to create a new product.

When changing an entity via the PATCH endpoint, you can send only the fields that you want to update, f.e. to change the product name send body {"name": "New name"}.

Use the state parameter in the connector URL to avoid CSRF ().

We recommend reading the section in this documentation for more details that apply to most of the .

The XML document () must be a valid and according to the mentioned . Put it as a value for the key named file in a form-data request body.

Document id attribute must be a valid in the form "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx".

More details about the endpoint and a sample XML document .

All info about .

describes the fields and their data types.

The GET endpoints return a or a

You can read more about , and in the General section.

The POST endpoint allows to .

The PATCH endpoint is to .

The PUT endpoint can create (like POST) or edit (like PATCH) or products.

Please do not round any price values ()

Please see the page for more info on the planned changes in validation.

We recommend to read more about since they are mandatory when editing entities.

integration@dotypos.com
Client Application registration form
Manual
more reading here
General
entity endpoints
UUID
Delivery notes is here
filters
sorting
paging
explained here
Breaking changes
ETags
structure described here
XSD file
validations
can be found here
Product schema
single product by its ID
list of filtered products.
create many products
edit a single product
one
more