{"_id":"584aeea99588370f00608aa1","githubsync":"","parentDoc":null,"version":{"_id":"584aeea89588370f00608a3b","project":"559ae8ec7ae7f80d0096d813","__v":1,"createdAt":"2016-12-09T17:49:28.502Z","releaseDate":"2016-12-09T17:49:28.502Z","categories":["584aeea89588370f00608a3c","584aeea89588370f00608a3d","584aeea89588370f00608a3e","584aeea89588370f00608a3f","584aeea89588370f00608a40","584aeea89588370f00608a41","584aeea89588370f00608a42","584aeea89588370f00608a43","584aeea89588370f00608a44","584aeea89588370f00608a45","584aeea89588370f00608a46","584aeea89588370f00608a47","584aeea89588370f00608a48","584aeea89588370f00608a49","584aeea89588370f00608a4a","584aeea89588370f00608a4b","584aeea89588370f00608a4c","584aeea89588370f00608a4d","584aeea89588370f00608a4e","584aeea89588370f00608a4f"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"4.2.3","version":"4.2.3"},"project":"559ae8ec7ae7f80d0096d813","category":{"_id":"584aeea89588370f00608a41","__v":0,"version":"584aeea89588370f00608a3b","project":"559ae8ec7ae7f80d0096d813","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-07-07T21:24:57.742Z","from_sync":false,"order":5,"slug":"integration-scenarios","title":"Integration scenarios"},"__v":0,"user":"559ae88c7ae7f80d0096d812","updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-07-07T21:24:33.336Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":0,"body":"[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Data processing essentials\"\n}\n[/block]\nSemantria is an asynchronous API. This means:\n  * You submit content to us and retrieve content separately.\n  * You can scale your content submission rates as you are not waiting on us to hand data back before you can submit more.\n  * You may receive data back in a different order than you submitted it. Batches of content are not necessarily preserved\n  * If you use the callback retrieval mechanism, the batches remain the same, but the order might be different\n  * If you use auto response or polling, the batch membership may also change\n  * If you have multiple machines sending and receiving content, one machine may receive a processed document that was submitted by another.\n  * Every piece of content is processed by a Semantria configuration. If you don't specify one, your default configuration will be used.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Handling Failures\"\n}\n[/block]\nThere are several types of failures during the submission and processing of content.\n1. The submission is itself invalid in some way such as invalid JSON. In this case no documents are queued, and no API credits are deducted. You need to correct the errors and resubmit. You will know the submission is invalid if you receive anything other than a 200-series HTTP status response.\n2. The submission is valid but the content itself is failed. In this case you will receive the document back, with a FAILED status and an error message stating why it was failed. Credits are deducted for this. In this case, you should not resubmit the piece of content that was failed, as it will simply fail again. The most common cases of document failure are submitting content to the wrong language (sending Arabic content to an English config for instance) and content that does not have enough text to analyze (such as ASCII art and the like)\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Keeping Track Of Your Content\"\n}\n[/block]\nBecause order and batch are not preserved on the Semantria side, it is up to you to keep track of what you submitted and received. There are several ways for you to identify your content.\n1. Each document can have a unique **id** associated with it. This is returned to you by Semantria when you receive the processed data. You can use this **id** to update the status on your side. Additionally, you can request the status of a document via its **id**.\n2. Each document can also have a tag field. This is a string field you can fill in with additional information you might use to keep track documents, such as a project ID. You can check on your side to see that you submitted 1,000 documents for tag \"my_project\" and received 1,000 documents back with that tag. You cannot request status on a tag.\n3. You can submit and retrieve by job_id. This is a string value you can set when you submit and retrieve documents. it is intended to allow you to separate out processing streams of content for routing or failover purposes on your side, not as a unique ID per batch of content.\n  * If you submit by a job_id, you must retrieve via that same job_id. Retrieving by config_id will not retrieve documents submitted with a job_id. This does not prevent you from setting the config_id when submitting with a job_id, you just cannot retrieve by that config_id.\n  * The total number of unique job_ids you use during a 24hr period must not exceed 100.\nNote\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"body\": \"It is possible to send two documents with the same document id, as long as you send them to different configurations. If you send two documents with the same document id to the same configuration, the latter document sent will overwrite the former. Data loss may occur.\",\n  \"title\": \"Duplicate Document ID\"\n}\n[/block]\n\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"body\": \"If a user tries to process a document or analysis that has already been sent and processed but has not yet been retrieved, the server will override the previous analysis, change its status to QUEUED, and process the newer document.\"\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Data Processing\"\n}\n[/block]\nThere are four types of processing a document or group of documents in a Semantria analysis.\n**Queue**: submit a document or batch of documents for Detailed analysis or submit a collection for Discovery analysis.\n  * Queue with a POST method and the server will return with an HTTP status.\n  * For example, queuing documents for analysis is like lining up bottles to be filled by the milkman.\n\n**Request**: determine the status of a certain document with its document ID.\n  * Request with a GET request and the server will respond with either the processed results of the current status: QUEUED, PROCESSED, or FAILED.\n  * For example, requesting a document is like asking the status of a specific bottle-- the milkman will either give you the filled bottle or tell you why you can't have it yet.\n  * In a request call, if the server responds with a \"PROCESSED\" status, it will also return the corresponding processed data.\n  * In a request call, if the server responds with a \"QUEUED\" or \"FAILED\" status, a corresponding reason or error will accompany it.\n\n**Retrieve**: return all processed documents.\n  * Retrieve with a GET request and the server will return the results of all documents that have been processed. It will return nothing if no documents are processed.\n  * For example, retrieving documents is like asking the milkman for any and all full bottles.\n\n**Cancel**: delete a queued document if Semantria has not processed it yet.\n  * This is a DELETE request.\n  * For example, cancelling a document is like removing the empty bottle before it has been filled by the milkman.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Detailed Mode Processing Methods\"\n}\n[/block]\n## Queuing Documents\n[block:callout]\n{\n  \"type\": \"info\",\n  \"body\": \"Queuing: submitting a document or batch of documents for Detailed analysis.\"\n}\n[/block]\nUsers must queue documents into the API for processing. A document can be processed with a specific configuration (by using a particular config_id) or with the default configuration (by passing nothing in the config_id field). Single documents under 2KB in size should come back in a few seconds.\n\n**One Document:**\nFor individual documents, the URL is https://api.semantria.com/ [document.json] | [document.xml] .\nThe **config_id** parameter should be submitted as part of the url. \nThe request body should contain an XML or JSON object with three fields: the document ID, the text to be analyzed, and an optional tag in the POST request.\nAfter submitting documents to be queued, each document will be analyzed independently of the others. Semantria API will return an analysis for each document.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"body\": \"The server will process each document independently of any other processes or documents. Documents will not influence each other in processing.\"\n}\n[/block]","excerpt":"","slug":"send-documents","type":"basic","title":"Processing Basics"}
[block:api-header] { "type": "basic", "title": "Data processing essentials" } [/block] Semantria is an asynchronous API. This means: * You submit content to us and retrieve content separately. * You can scale your content submission rates as you are not waiting on us to hand data back before you can submit more. * You may receive data back in a different order than you submitted it. Batches of content are not necessarily preserved * If you use the callback retrieval mechanism, the batches remain the same, but the order might be different * If you use auto response or polling, the batch membership may also change * If you have multiple machines sending and receiving content, one machine may receive a processed document that was submitted by another. * Every piece of content is processed by a Semantria configuration. If you don't specify one, your default configuration will be used. [block:api-header] { "type": "basic", "title": "Handling Failures" } [/block] There are several types of failures during the submission and processing of content. 1. The submission is itself invalid in some way such as invalid JSON. In this case no documents are queued, and no API credits are deducted. You need to correct the errors and resubmit. You will know the submission is invalid if you receive anything other than a 200-series HTTP status response. 2. The submission is valid but the content itself is failed. In this case you will receive the document back, with a FAILED status and an error message stating why it was failed. Credits are deducted for this. In this case, you should not resubmit the piece of content that was failed, as it will simply fail again. The most common cases of document failure are submitting content to the wrong language (sending Arabic content to an English config for instance) and content that does not have enough text to analyze (such as ASCII art and the like) [block:api-header] { "type": "basic", "title": "Keeping Track Of Your Content" } [/block] Because order and batch are not preserved on the Semantria side, it is up to you to keep track of what you submitted and received. There are several ways for you to identify your content. 1. Each document can have a unique **id** associated with it. This is returned to you by Semantria when you receive the processed data. You can use this **id** to update the status on your side. Additionally, you can request the status of a document via its **id**. 2. Each document can also have a tag field. This is a string field you can fill in with additional information you might use to keep track documents, such as a project ID. You can check on your side to see that you submitted 1,000 documents for tag "my_project" and received 1,000 documents back with that tag. You cannot request status on a tag. 3. You can submit and retrieve by job_id. This is a string value you can set when you submit and retrieve documents. it is intended to allow you to separate out processing streams of content for routing or failover purposes on your side, not as a unique ID per batch of content. * If you submit by a job_id, you must retrieve via that same job_id. Retrieving by config_id will not retrieve documents submitted with a job_id. This does not prevent you from setting the config_id when submitting with a job_id, you just cannot retrieve by that config_id. * The total number of unique job_ids you use during a 24hr period must not exceed 100. Note [block:callout] { "type": "warning", "body": "It is possible to send two documents with the same document id, as long as you send them to different configurations. If you send two documents with the same document id to the same configuration, the latter document sent will overwrite the former. Data loss may occur.", "title": "Duplicate Document ID" } [/block] [block:callout] { "type": "warning", "body": "If a user tries to process a document or analysis that has already been sent and processed but has not yet been retrieved, the server will override the previous analysis, change its status to QUEUED, and process the newer document." } [/block] [block:api-header] { "type": "basic", "title": "Data Processing" } [/block] There are four types of processing a document or group of documents in a Semantria analysis. **Queue**: submit a document or batch of documents for Detailed analysis or submit a collection for Discovery analysis. * Queue with a POST method and the server will return with an HTTP status. * For example, queuing documents for analysis is like lining up bottles to be filled by the milkman. **Request**: determine the status of a certain document with its document ID. * Request with a GET request and the server will respond with either the processed results of the current status: QUEUED, PROCESSED, or FAILED. * For example, requesting a document is like asking the status of a specific bottle-- the milkman will either give you the filled bottle or tell you why you can't have it yet. * In a request call, if the server responds with a "PROCESSED" status, it will also return the corresponding processed data. * In a request call, if the server responds with a "QUEUED" or "FAILED" status, a corresponding reason or error will accompany it. **Retrieve**: return all processed documents. * Retrieve with a GET request and the server will return the results of all documents that have been processed. It will return nothing if no documents are processed. * For example, retrieving documents is like asking the milkman for any and all full bottles. **Cancel**: delete a queued document if Semantria has not processed it yet. * This is a DELETE request. * For example, cancelling a document is like removing the empty bottle before it has been filled by the milkman. [block:api-header] { "type": "basic", "title": "Detailed Mode Processing Methods" } [/block] ## Queuing Documents [block:callout] { "type": "info", "body": "Queuing: submitting a document or batch of documents for Detailed analysis." } [/block] Users must queue documents into the API for processing. A document can be processed with a specific configuration (by using a particular config_id) or with the default configuration (by passing nothing in the config_id field). Single documents under 2KB in size should come back in a few seconds. **One Document:** For individual documents, the URL is https://api.semantria.com/ [document.json] | [document.xml] . The **config_id** parameter should be submitted as part of the url. The request body should contain an XML or JSON object with three fields: the document ID, the text to be analyzed, and an optional tag in the POST request. After submitting documents to be queued, each document will be analyzed independently of the others. Semantria API will return an analysis for each document. [block:callout] { "type": "info", "body": "The server will process each document independently of any other processes or documents. Documents will not influence each other in processing." } [/block]