Memsource REST API

REST API Overview

Memsource offers a set of API calls which allow for:

  • Integration of Memsource and any third party software (translation management tools, CMSs, etc.)

  • Development of a translator's workbench. Memsource Editor is built on top of public APIs.

  • Creation of a brand new tool or service which uses Memsource in its backend.

Developer Edition

To start using Memsource REST APIs, sign up for the Memsource Developer edition. This free edition is designed to be used as a sandbox for API development. Users can use Postman to learn about and test Memsource APIs.

Developer edition restrictions:

Developers may use this edition for development and testing purposes only. Contact Memsource Technical Support if you need these limits increased or modified.

  • A maximum of 2 translation jobs stored at any time

  • A maximum of 1 MB for job file sizes

  • A maximum of 1 Administrator user and 1 Linguist user

Memsource REST API documentation is available on a dedicated site. It is automatically generated and can be downloaded and exported.

Basic Workflow

Memsource procedures and workflow must be understood before using Memsource APIs. It is recommended to be familiar with a procedure in the Memsource application before implementing the related API.

The basic workflow is:

  1. Create a TM, TB, and optionally, add a machine translation engine.

  2. Create a project with the TM/TB/machine translation engine attached (if needed).

  3. Upload your file for translation to the project (also called creating a job in Memsource).

  4. You can then analyze, pre-translate or assign the job to a Linguist.

Asynchronous APIs

Asynchronous APIs should always be preferred to their synchronous counterparts. If calling synchronous APIs, there is a chance of receiving timeout expired responses when processing large batches of files or even a single large file. Synchronous APIs should only be used for small files and small scale Memsource integration.


After calling an asynchronous API, an instant response is received including the identifier request. Use this identifier to check the status of the request by calling getAsyncRequest and checking the asyncResponse field. This polling approach can lead to a number of getAsyncRequest calls before receiving an asyncResponse that is not null.


As a response to the drawbacks of the polling approach to asynchronous requests, support for callbacks in all asynchronous APIs is supported. When calling an asynchronous request, specify a URL (in the callbackUrl parameter) that is requested after the work initiated by the asynchronous request is complete.

Callbacks are requested via HTTP POST calls and the data is passed on in the body encoded as JSON. The JSON object always contains:

  • Information about the asynchronous request (the same as when calling getAsyncRequest).

  • Detailed information about the result of the action such as a full analysis or job details.

   "asyncRequest": {
 "analyse": {   

If a callback URL is not accessible, the request is repeated after 2, 4, 8, 16, and 30 minutes until 10 retries have failed.

Your callback URL must respond with the 200 OK HTTP status code to be considered successful on our side.

Callback URL must respond with the 200 OK HTTP status code to be considered successful.If the Include subfolders option is selected in API:

Was this article helpful?

Sorry about that! In what way was it not helpful?

The article didn’t address my problem.
I couldn’t understand the article.
The feature doesn’t do what I need.
Other reason.

Note that feedback is provided anonymously so we aren't able to reply to questions.
If you'd like to ask a question, submit a request to our Support team.
Thank you for your feedback.