You may process transactions using the Service for your own internal use or on behalf of your paying customers who use your recruiting system, unless otherwise prohibited by the Tx Platform Terms of Service or this policy.
You warrant that, for each transaction subject to the European GDPR, the data owner has consented to such processing (which may have been obtained by your customer or another party), and you will not knowingly process any data that belongs to a person of less than adult legal age. You may not send data to the Services for vendor-specific geocoding that does not comply with that vendor’s terms of service and acceptable use policies.
You may not use the Service, or the results obtained from use of the Service in whole or in part, in or in conjunction with, or as a part of, any system, method, manner, or process of any kind which violates the intellectual property rights, privacy rights or other legally enforceable rights of any third party, and you agree to indemnify, defend and hold harmless Provider from all claims, allegations, proceedings, judgments, settlements, and damages of any and every kind arising therefrom.
You may not use the Services or the results of the Services in any system, business or process which, in the opinion of Provider, has the intent or effect of reducing or potentially reducing, the demand of other third parties for Provider’s parsing software or services.
You agree to safeguard the credentials to the Service to prevent their theft or misuse.
You may not knowingly send malformed documents, nor documents containing malicious code, nor unsupported document types to the Service.
You may not re-submit a document to the Service if (1) a prior processed transaction of that document contained a return code from the Service indicating that the document was corrupt or of an unsupported type, or (2) the document text field in the response was empty, or (3) the transaction returned an exception which included this phrase:
“System.Net.WebException: The underlying connection was closed”, or (4) the document was previously submitted twice and failed to process without error both times.
You may not in any way attempt to reverse engineer or otherwise re-create the Textkernel skills lists during your use of the Textkernel Skills Editor, nor by any other method. Any attempts to re-type, copy and paste, create screenshots, etc., are strictly prohibited.
You may not “ping” the Service more than once a day, nor retrieve the WSDL from the Service more than once per day, nor retrieve your account information (REST | SOAP) more than twice per day unless in conjunction with a Batch Transaction.
You may not use the Service to process documents unrelated to recruitment. You may not perform scalability testing of any kind, nor process any transactions through the Service with the intent of determining when the Service will or is likely to become overwhelmed.
You must institute processing safeguards and kill switches to ensure that you do not violate this AUP. Please note that without explicitly programming checks to test whether a transaction failed and whether the document can be legally resubmitted in accordance with this AUP, you will eventually violate this AUP and probably use all your account credits – and more – in a “futile loop of Einsteinian doom”. An example of a “futile loop of Einsteinian doom” is logic such as this:
NEVER EVER IMPLEMENT THIS TYPE OF LOGIC
The problem with the above loop is that when a particular document fails, it will be resubmitted for processing an infinite number of times, but with no chance that the 765,498th time, or any other time, it will magically succeed.
You must also institute safeguards to ensure that you do not submit transactions to the Service for processing when you have no available credits.
Every transaction returns an approximate amount of available credits (due to concurrency it is not possible to give an exact figure), and you should make sure that you check and use that value to prevent “going negative”.
Please note that ALL chargeable transactions submitted to the service will incur a charge, even if the transaction was not successful.
CONCURRENCY LIMITS
An “Ad Hoc Transaction” refers to a transaction that is initiated by a human being to immediately process a single resume or job, or to perform a single search or match. An Ad Hoc Transaction is a single transaction that by its very nature is not scheduled or controlled by Recipient as to time of submission because it must be processed in real time and the results returned in real time to the waiting human. A candidate uploading her resume, or a recruiter uploading a single document to be parsed or matched, would be a typical Ad Hoc transaction. An single immediate follow-on transaction that would automatically perform a match for a candidate’s resume that she just submitted and parsed, would also count as anAd Hoc transaction.
Ad Hoc Transactions are not subject to the concurrency limitations on Batch Transactions, and may be submitted at any time, even during a Batch Transaction, and in no case will Ad Hoc Transactions be counted against the Maximum Allowable Number of Concurrent Batch Transactions.
Again, Ad Hoc transactions are not subject to concurrency limitations as they are not controlled by you and are initiated by human end-users. However, Batch Transactions are controllable by you and are subject to the concurrency limits described below.
A “Batch Transaction” is any transaction that is not an Ad Hoc Transaction, such as a transaction submitted to the Service for processing by a program that is iterating through and submitting multiple documents to the Service for processing. In such case, each such document submitted constitutes a separate Batch Transaction. [For a sample program with full source code to process batch transactions, contact service@textkernel.com.]
You may not submit, in aggregate from all processes using your Service credentials, batch transactions to the Service at a rate that exceeds the Maximum Allowable Number of Concurrent Batch Transactions. This is 100% in your control. In order to determine your current Maximum Allowable Number of Concurrent Batch Transactions, you must programmatically retrieve your account information from the Service (REST | SOAP) and obtain the MaximumConcurrentRequests value that is returned, immediately prior to processing Batch Transactions, and after every 1,000 transactions processed within the batch. Exceeding the Maximum Allowable Number of Concurrent Batch Transactions may result in any or all of (a) suspension of your account, (b) permanent termination of your account, (c) additional charges, (d) rejection of excess transactions.
In other words, once you have submitted the Maximum Allowable Number of Concurrent Batch Transactions to the Service (“the current transactions”), an additional Batch Transaction, whether from the same process or any other batch process submitting with your credentials, may be submitted only when, and as, the Service has returned the results of its processing of one of the submitted transactions.
You may request larger levels of Maximum Allowable Number of Concurrent Batch Transactions to the Service. If you need to run, say, a batch of 1,000,000 transactions by submitting 1,000 concurrent transactions, we can work with you to allow this (with sufficient advance notice, and for a fee to cover increased hosting costs).
You MUST pass the correct (or a good-faith estimate) RevisionDate (in version 10, the DocumentLastModified) for every resume that you send to the Service for parsing.
You must store, in your own systems, all data that is sent to the Service and all data that is returned by the Service for as long as you may need to retrieve or reference that data, or to rebuild the AI Matching indexes. The Service is NOT intended to be used for storage and retrieval; you must use your own data storage for that purpose. The Service stores parsed documents that you place into your AI Matching indexes for 18 months, as measured by the older of the RevisionDate (v9), DocumentLastModified (v10), or the date that the transaction was executed. The Service periodically removes documents older than that date from all indexes, and will provide you with two downloads: (i) a list of all document IDs of documents that were deleted (ii) a list of all document IDs that remain in the index. You must not resubmit documents for indexing that were removed by the Service. Should you wish the Service to retain all documents in the indexes for longer periods, you may request such in writing, specifying the period, and stating that you will be responsible for the charges. Textkernel will then bill you every 6 months for each “extended storage” document in each index at the rate of 1 credit per document that is calculated as older than 18 months, and you will be invoiced accordingly.
You may submit unlimited Ad Hoc transactions to the AI Matching endpoints (search, bimetric scoring, or AI Matching). You may not submit more than 100 non-Ad Hoc search, bimetric scoring, or AI Matching transactions per day unless you prior negotiate a higher limit with us.
You may not modify a parsed document before adding it to an AI Matching index in the Service. Textkernel scrubs all found PII from parsed documents prior to indexing. You make a continuing warranty that you will not inject PII into the Services’ AI Matching indexes in any form or manner whatsoever, including by use of custom IDs or custom values.
YOUR CONSENT TO SECURE PRACTICES
Documents that are sent to Service that cause a severe operational error will be examined immediately by a trained security specialist for malicious code or payloads. Such analyses shall be accomplished and all recommended remediation steps shall have begun within 24 hours, and the documents permanently destroyed using secure practices.
When you exceed the Maximum Allowable Number of Concurrent Batch Transactions, the Service may reject excess transactions without processing, using a “429 Too Many Requests” response code, but will not supply a valid value for “Retry-After”. Transactions that are not excessive will continue to process normally, meaning that only excess transactions will ever be rejected.
Excess transactions that are rejected with a 429 response code will consume the same number of credits as normal transactions, so do not rely on rejected submissions as a substitute for correct multithreaded batch programming on your side. As always, contact service@textkernel.com anytime for assistance in understanding and implementing best practices.
PROTECTIVE MEASURES
Violation of any part of this Acceptable Use Policy, intentionally or unintentionally, shall be grounds for immediate suspension or termination of your access to the Service. We may suspend and/or terminate you if Provider determines that you are using the Service in such a way as to negatively impact our ongoing business interests or competes against the Service. Suspension and/or termination of access are at our sole discretion.
