The Availity connector lets your AI agent act in each user's Availity account. Each user signs in to Availity once, and Scalekit stores and refreshes their tokens, so your agent never handles credentials. It comes with 11 tools.
- Tools
- 11
- What they doRead · write · destructive
- 8 · 2 · 18 read2 write1 destructive
- Users sign in with
- Service account
Setup
Install the SDK
Terminal window npm install @scalekit-sdk/node dotenvTerminal window pip install scalekit-sdk-python python-dotenvSet your credentials
Add your Scalekit credentials to your
.envfile. Find values in app.scalekit.com > Developers > API Credentials..env SCALEKIT_ENVIRONMENT_URL=<your-environment-url>SCALEKIT_CLIENT_ID=<your-client-id>SCALEKIT_CLIENT_SECRET=<your-client-secret>Create the Availity connection
In AgentKit > Connections, create an Availity connection. The name you give it is the
connection_nameyour code passes. See Configure connections.Console steps with screenshots
Availity connections use OAuth 2.0 client credentials: the API key and secret of an app on the Availity Developer Portal. The credentials belong to your provider organization, so tool calls act for the organization rather than an individual clinician. Scalekit exchanges the credentials for a short-lived access token and refreshes it.
-
Create an app on the Availity Developer Portal
On the Availity Developer Portal, create an app and subscribe it to the HIPAA Transactions API product, on the Demo or Standard plan. Under My Apps > your app > Approved Access > Client info, copy the API Key and the Secret. The secret is shown only once; reset it under My Apps if you lose it.
Note the scopes the portal lists in your API product’s details.
-
Create the connection
In the Scalekit dashboard, go to AgentKit > Connections > Create Connection, find Availity and click Create. Select the scopes your API product lists, such as
hipaa, and click Save. The connection name is theconnection_nameyour code passes. -
Add a connected account
To test, open the connection, click the Connected Accounts tab > Add Account, enter the user’s identifier, such as
user_123, and fill in:- API Key (Client ID): the app’s API key. It’s case sensitive.
- Secret (Client Secret): the app’s secret.
In production, the authorization link collects the same two fields.
-
Tools
Pass the exact name toexecute_toolavaility_claim_status_getGet the full claim status response (X12 277) for one claim status ID.Read-onlyGet Claim Status
Get the full claim status response (X12 277) for one claim status ID. Returns status and statusCode, payer, submitter, providers, subscriber, patient and claimStatuses with claim control numbers, statusDetails (category, status code, claim and payment amounts, finalized and remittance dates, check number) and serviceLines. Use claim_status_get after claim_statuses_search returns an id. Use claim_statuses_search to start a new inquiry.
Inputs
claim_status_idstringrequired- The claim status ID returned by claim_statuses_search (the id field of a claimStatuses item). Example: 5334032768852043884
availity_claim_statuses_searchSend a claim status inquiry (X12 276) to a health plan through Availity for claims matching the given payer, provider, member and service dates.Read-onlyCheck Claim Status
Send a claim status inquiry (X12 276) to a health plan through Availity for claims matching the given payer, provider, member and service dates. Returns HTTP 202 with an empty claimStatuses list while the payer is processing, then claimStatuses summaries with id, status, statusCode, claimNumber, claimAmount and dates. Use claim_statuses_search to start the inquiry and repeat the same call to poll. Use claim_status_get with a returned id for the full 277 detail, including status codes, payments and service lines. Use configurations_list with type claim-statuses-inquiry to see which fields the payer requires.
Inputs
payer_idstringrequired- Availity-specific identifier of the health plan that processed the claim, from payers_list. Example: BCBSF
claim_amountstring- Total charge amount on the claim, as a decimal string. Example: 150.00
claim_numberstring- The health plan's claim tracking number assigned when the claim was received. Example: CLM0001
facility_type_codestring- Where services were performed: a place of service code for professional claims (X12 code source 237, e.g. 11 office) or a bill type for institutional claims (code source 236, e.g. 13 hospital outpatient).
frequency_type_codestring- Claim frequency type code (X12 code source 235), such as 1 (original claim) or 7 (replacement).
from_datestring- First date of service on the claim, as YYYY-MM-DD. Example: 2026-01-05
patient_account_numberstring- The provider's own account or reference number for the patient, as sent on the claim. Example: ACCT-0001
patient_birth_datestring- The patient's date of birth as YYYY-MM-DD. Example: 1980-01-01
patient_first_namestring- The patient's first name. Example: SAMPLE
patient_gender_codestring- The patient's gender code: F (female) or M (male).one of
FM patient_last_namestring- The patient's last name, when the patient is not the subscriber. Example: TESTPATIENT
patient_subscriber_relationship_codestring- X12 837 individual relationship code of the patient to the subscriber, such as 18 (self), 01 (spouse) or 19 (child).
payer_assigned_provider_idstring- The health plan-assigned ID of the service provider. Example: P12345
provider_first_namestring- First name of the service provider, when the provider is a person. Example: ALEX
provider_last_namestring- Last name or business name of the service provider on the claim. Example: EXAMPLE CLINIC
provider_npistring- The service provider's 10-digit NPI. Example: 1234567893
provider_tax_idstring- The service provider's 9-digit tax ID with no dashes. Example: 123456789
submitter_first_namestring- First name of the claim submitter, when the submitter is a person. Example: ALEX
submitter_idstring- The submitter's identifier, for health plans that require it. Example: G12345
submitter_last_namestring- Last name or business name of the claim submitter. Example: EXAMPLE CLINIC
subscriber_first_namestring- The subscriber's first name. Example: SAMPLE
subscriber_last_namestring- The subscriber's last name. Example: TESTPATIENT
subscriber_member_idstring- The subscriber's health plan member ID. Example: ABC123456789
to_datestring- Last date of service on the claim, as YYYY-MM-DD. Example: 2026-01-05
availity_configurations_listGet a payer's field requirements and validation rules for a transaction type, or list the payers that support that transaction.Read-onlyList Payer Configurations
Get a payer's field requirements and validation rules for a transaction type, or list the payers that support that transaction. Returns configurations with type, payerId, payerName, and elements describing each field's label, required flag, allowed values, pattern and max length, plus requiredFieldCombinations. Use configurations_list before coverage_create, claim_statuses_search or service_review_create to learn which fields a payer requires. Use payers_list to find payer IDs.
Inputs
typestringrequired- The transaction type to get configuration for. 270 = eligibility and benefits (coverages), service-reviews = creating an authorization or referral, service-reviews-inquiry = searching authorizations, claim-statuses-inquiry = claim status, professional-claims / institutional-claims = patient cost estimates, enhanced-claim-status = Enhanced Claim Status add-on.one of
270service-reviewsservice-reviews-inquiryclaim-statuses-inquiryprofessional-claimsinstitutional-claimsenhanced-claim-status limitinteger- Maximum number of configurations to return, from 1 to 50. Default 50.
offsetinteger- Zero-based index of the first configuration to return, for paging. Default 0.
payer_idstring- Availity payer ID whose rules you want. Leave empty to list every payer that supports the transaction type. Example: BCBSF
subtype_idstring- Subtype for the transaction type. For service-reviews and service-reviews-inquiry: HS (outpatient authorization), AR (inpatient authorization / admission review) or SC (referral). For professional-claims and institutional-claims: PRE_DETERMINATION. For enhanced-claim-status: HIPAA_276, VALUE_ADDS_277, SUMMARY or DETAIL. Leave empty for 270 and claim-statuses-inquiry.
availity_coverage_createSend an eligibility and benefits inquiry (X12 270) for a patient to their health plan through Availity.Read-onlyCheck Eligibility and Benefits
Send an eligibility and benefits inquiry (X12 270) for a patient to their health plan through Availity. Returns the coverage with its id, status and statusCode (0 In Progress, 4 Complete, other codes are errors), and once complete the payer, subscriber, patient and plans with benefits. Use coverage_create to start a check. When statusCode is 0, poll coverage_get with the returned id every few seconds until it changes. Use configurations_list with type 270 to see which fields the payer requires.
Inputs
payer_idstringrequired- Availity-specific identifier of the patient's health plan, from payers_list. Example: BCBSF
service_typestringrequired- X12 270 service type code for the benefits to check. 30 = Health Benefit Plan Coverage (general eligibility). Other common codes: 1 (Medical Care), 33 (Chiropractic), 35 (Dental Care), 47 (Hospital), 48 (Hospital Inpatient), 50 (Hospital Outpatient), 86 (Emergency Services), 88 (Pharmacy), 98 (Professional Physician Visit - Office), MH (Mental Health), UC (Urgent Care). One code per request.
as_of_datestring- Date of service to check coverage for, as YYYY-MM-DD. Defaults to today at the health plan. Example: 2026-01-15
card_issue_datestring- Issue date on the member's health plan card, as YYYY-MM-DD, for plans that require it. Example: 2025-01-01
group_numberstring- The patient's health plan group number. Example: GRP12345
medicaid_idstring- The patient's Medicaid ID number, for Medicaid plans. Example: 123456789012
member_idstring- The patient's or subscriber's health plan member ID as printed on the card. Example: ABC123456789
mock_scenario_idstring- Demo plan only. ID of the canned response scenario Availity's Demo plan should return, sent as the X-Api-Mock-Scenario-ID header. Leave empty on the Standard (production) plan. Valid IDs for this operation: Coverages-Complete-i, Coverages-InProgress-i, Coverages-Retrying-i, Coverages-PayerError1-i, Coverages-PayerError2-i, Coverages-RequestError1-i, Coverages-RequestError2-i.
patient_birth_datestring- The patient's date of birth as YYYY-MM-DD. Most health plans require it. Example: 1980-01-01
patient_first_namestring- The patient's first name. Example: SAMPLE
patient_genderstring- The patient's gender code: M (male), F (female) or U (unknown).one of
MFU patient_last_namestring- The patient's last name. Example: TESTPATIENT
patient_middle_namestring- The patient's middle name or initial. Example: Q
patient_statestring- Two-letter code of the patient's state of residence, for plans that require it. Example: FL
patient_suffixstring- The patient's name suffix. Example: JR
payer_assigned_provider_idstring- An identifier the health plan assigned to the requesting provider, for plans that accept one. Example: P12345
place_of_servicestring- Place of service code, for health plans that require it (X12 code source 237). Example: 11 (office)
procedure_codestring- Procedure code to check benefits for, such as a CPT or HCPCS code, for plans that support procedure-level inquiries. Example: 99213
provider_citystring- The requesting provider's city, for health plans that require it. Example: JACKSONVILLE
provider_first_namestring- The requesting provider's first name, when the provider is a person. Example: ALEX
provider_last_namestring- The requesting provider's last name or organization name. Example: EXAMPLE CLINIC
provider_npistring- The requesting provider's 10-digit National Provider Identifier. Most health plans require it. Example: 1234567893
provider_specialtystring- The requesting provider's specialty as an X12 provider taxonomy code (code source 682). Example: 207Q00000X
provider_statestring- The requesting provider's two-letter state code, for health plans that require it. Example: FL
provider_tax_idstring- The requesting provider's 9-digit tax ID with no dashes, for health plans that require it. Example: 123456789
provider_zip_codestring- The requesting provider's ZIP code, for health plans that require it. Example: 32202
submitter_idstring- A payer-assigned submitter identifier, for health plans that require it. Example: G12345
subscriber_relationshipstring- The patient's relationship to the subscriber when the patient is not the subscriber: 18 (self), 01 (spouse), 19 (child) or G8 (other relationship).one of
180119G8 to_datestring- End date of the coverage period to check, as YYYY-MM-DD, for health plans that support a date range. Example: 2026-01-31
availity_coverage_getGet an eligibility and benefits (X12 271) result by its coverage ID.Read-onlyGet Eligibility and Benefits
Get an eligibility and benefits (X12 271) result by its coverage ID. Returns the coverage with status and statusCode, payer, requestingProvider, subscriber, patient, plans (coverage status, group number, dates and benefits) and any validationMessages from the payer. Use coverage_get to poll a check started with coverage_create until statusCode is no longer 0 (In Progress). Results expire at expirationDate.
Inputs
coverage_idstringrequired- The coverage response ID returned by coverage_create (the id field). Example: 7276849100383928590
mock_scenario_idstring- Demo plan only. ID of the canned response scenario Availity's Demo plan should return, sent as the X-Api-Mock-Scenario-ID header. Leave empty on the Standard (production) plan. Valid IDs for this operation: Coverages-Complete-i, Coverages-InProgress-i, Coverages-Retrying-i, Coverages-PayerError1-i, Coverages-PayerError2-i.
availity_payers_listList the health plans (payers) available through Availity on your contract, optionally filtered by payer ID, supported transaction type or submission mode.Read-onlyList Payers
List the health plans (payers) available through Availity on your contract, optionally filtered by payer ID, supported transaction type or submission mode. Returns each payer's name, payerId, displayName, shortName and processingRoutes (transaction, submission mode, enrollment requirement, effective date). Use payers_list to find the payerId that coverage_create, claim_statuses_search and service_review_create need. Use configurations_list for a payer's field-level validation rules.
Inputs
availabilitystring- Filter by contract requirement: available returns payers that do not need an additional Availity contract, contractrequired returns payers that do.one of
availablecontractrequired enrollment_requiredboolean- Filter by whether enrollment with Availity is required to submit the transaction. true returns only payers that need enrollment; false only those that do not.
payer_idstring- Availity-specific payer identifier to look up a single payer. Leave empty to list every payer on your contract. Example: BCBSF
submission_modesarray- Only return payers that accept the transactions through these submission methods: Portal, Batch, RealTime or API. Example: ["API"]
transaction_typesarray- Only return payers that support these EDI transaction types. Common values: 270 (eligibility and benefits), 276 (claim status), 278I (service review / prior authorization inquiry), 835 (remittance), 837P and 837I (professional and institutional claims). Example: ["270", "276"]
availity_service_review_getGet one prior authorization or referral (service review) by its ID, including the payer's decision.Read-onlyGet Service Review
Get one prior authorization or referral (service review) by its ID, including the payer's decision. Returns status and statusCode (for example A1 Certified in Total, A4 Pended), certificationNumber, referenceNumber, certification dates, updatable and deletable flags, updatableFields, payerNotes, validationMessages, diagnoses, procedures and providers. Use service_review_get to poll a review submitted with service_review_create or to read one found with service_reviews_search.
Inputs
service_review_idstringrequired- The service review ID returned by service_review_create or service_reviews_search (the id field). Example: 12345678
mock_scenario_idstring- Demo plan only. ID of the canned response scenario Availity's Demo plan should return, sent as the X-Api-Mock-Scenario-ID header. Leave empty on the Standard (production) plan. Valid IDs for this operation: SR-GetComplete-i, SR-GetInProgress-i, SR-GetRetrying-i, SR-GetPayerDown-i (with ID 12345678).
availity_service_reviews_searchSearch a health plan's system for existing prior authorizations and referrals (X12 278 inquiry) by payer, provider, member, patient, dates or certification and reference numbers.Read-onlySearch Service Reviews
Search a health plan's system for existing prior authorizations and referrals (X12 278 inquiry) by payer, provider, member, patient, dates or certification and reference numbers. Returns HTTP 202 while the payer is being queried, then serviceReviews with id, status, statusCode, certificationNumber or referenceNumber, requestType, serviceType and dates. Use service_reviews_search to check whether an authorization exists or to find one to update or void. Use service_review_get when you already have the id. Use configurations_list with type service-reviews-inquiry to see which search fields the payer requires.
Inputs
certification_issue_datestring- Date the authorization certification was issued, as YYYY-MM-DD. Example: 2026-02-01
certification_numberstring- Number the health plan assigned once the authorization was certified. Example: 1231723
from_datestring- Service beginning date, as YYYY-MM-DD. Example: 2026-02-01
mock_scenario_idstring- Demo plan only. ID of the canned response scenario Availity's Demo plan should return, sent as the X-Api-Mock-Scenario-ID header. Leave empty on the Standard (production) plan. Valid IDs for this operation: SRI-GetComplete-i, SRI-GetAccepted-i, SRI-GetInProgress-i, SRI-GetRetrying-i, SRI-GetPayerError-i, SRI-GetPayerDown-i, SRI-GetRequestError-i.
patient_birth_datestring- The patient's date of birth as YYYY-MM-DD. Example: 1980-01-01
patient_first_namestring- The patient's first name. Example: SAMPLE
patient_last_namestring- The patient's last name. Example: TESTPATIENT
patient_subscriber_relationship_codestring- Patient's relationship to the subscriber: 18 (self), 01 (spouse), 19 (child) or G8 (other).one of
180119G8 payer_idstring- Availity-specific identifier of the patient's health plan. Example: BCBSF
reference_numberstring- Number the health plan assigned to a submitted request while under review; often called the case or authorization number. Example: REF12345
request_type_codestring- Type of review to search: HS (outpatient authorization), AR (inpatient admission review) or SC (referral).one of
HSARSC requesting_provider_first_namestring- The requesting provider's first name. Example: ALEX
requesting_provider_last_namestring- The requesting provider's last or business name. Example: EXAMPLE CLINIC
requesting_provider_npistring- The requesting provider's 10-digit NPI. Example: 1234567893
requesting_provider_specialty_codestring- The requesting provider's taxonomy code (X12 code source 682). Example: 207Q00000X
requesting_provider_submitter_idstring- The requesting provider's payer-specific submitter ID. Example: G12345
requesting_provider_tax_idstring- The requesting provider's tax ID, no dashes. Example: 123456789
session_idstring- Poll a search that is still running: pass the sessionId from the Location of an earlier 202 response (valid for 24 hours). When set, send no other search fields. Example: -1283121411
status_codestring- Only return reviews with this status code, for example A1 (Certified in Total) or A4 (Pended).
subscriber_first_namestring- The subscriber's first name. Example: SAMPLE
subscriber_last_namestring- The subscriber's last name. Example: TESTPATIENT
subscriber_member_idstring- The subscriber's health plan member ID. Example: ABC123456789
to_datestring- Service end date, as YYYY-MM-DD. Example: 2026-02-28
availity_service_review_createSubmit a prior authorization or referral request (X12 278) to a health plan through Availity: an outpatient authorization (HS), inpatient admission review (AR) or specialty care referral (SC).WriteCreate Service Review
Submit a prior authorization or referral request (X12 278) to a health plan through Availity: an outpatient authorization (HS), inpatient admission review (AR) or specialty care referral (SC). Returns HTTP 202 with the service review's id, status and statusCode, the submitted fields and any validationMessages, while Availity sends it to the payer. Use service_review_create to submit a new request, then poll service_review_get with the returned id for the payer's decision. Use configurations_list with type service-reviews and the matching subtype (HS, AR or SC) first to learn the payer's required fields.
Inputs
patientobjectrequired- The patient: firstName, lastName, birthDate (YYYY-MM-DD), genderCode (M or F) and subscriberRelationshipCode (18 self, 01 spouse, 19 child, G8 other), plus address fields if the payer requires them. Example: {"firstName": "SAMPLE", "lastName": "TESTPATIENT", "birthDate": "1980-01-01", "genderCode": "F", "subscriberRelationshipCode": "18"}
payerobjectrequired- The patient's health plan. Needs the Availity payer id; name is optional. Example: {"id": "BCBSF", "name": "FLORIDA BLUE"}
request_type_codestringrequired- Type of review: HS (Health Services Review, outpatient authorization), AR (Admission Review, inpatient authorization) or SC (Specialty Care Review, referral).one of
HSARSC requesting_providerobjectrequired- The provider requesting the authorization or referral: name (lastName for an organization, plus firstName for a person), npi, and the taxId, submitterId, specialtyCode (taxonomy), address (addressLine1, city, stateCode, zipCode) and contact (contactName, phone, fax) fields the payer requires. Field names follow Availity's Service Reviews schema. Example: {"lastName": "EXAMPLE CLINIC", "npi": "1234567893", "specialtyCode": "207Q00000X", "addressLine1": "1 MAIN ST", "city": "JACKSONVILLE", "stateCode": "FL", "zipCode": "32202", "contactName": "FRONT DESK", "phone": "5555550100"}
subscriberobjectrequired- The health plan subscriber: memberId, plus firstName and lastName and any address fields the payer requires. Example: {"memberId": "ABC123456789", "firstName": "SAMPLE", "lastName": "TESTPATIENT"}
additional_fieldsobject- Any other Service Reviews fields the payer requires, merged into the request as-is, for example transport, oxygen, home health or chiropractic details, or providerNotes. Field names follow Availity's Service Reviews schema. Example: {"providerNotes": [{"message": "Prior conservative therapy completed"}]}
admission_source_codestring- Inpatient admissions only: admission source code, such as 1 (physician referral) or 4 (transfer from a hospital).
admission_type_codestring- Inpatient admissions only: admission type code (X12 code source 231), such as 1 (emergency), 2 (urgent) or 3 (elective).
diagnosesarray- Diagnoses supporting the request. Each item has a qualifierCode (ABK for the principal ICD-10-CM diagnosis, ABF for others) and the ICD-10 code. Example: [{"qualifierCode": "ABK", "code": "M54.50"}]
from_datestring- Service or admission start date, as YYYY-MM-DD. Example: 2026-02-01
mock_scenario_idstring- Demo plan only. ID of the canned response scenario Availity's Demo plan should return, sent as the X-Api-Mock-Scenario-ID header. Leave empty on the Standard (production) plan. Valid IDs for this operation: SR-CreateRequestAccepted-i, SR-CreateRequestError-i.
place_of_service_codestring- Place of service code (X12 code source 237 for professional, 236 for institutional). Examples: 11 (office), 21 (inpatient hospital), 22 (outpatient hospital).
proceduresarray- Procedures being requested. Each item has a qualifierCode (HC for CPT/HCPCS), the procedure code, and optionally fromDate, toDate, quantity and quantityTypeCode. Example: [{"qualifierCode": "HC", "code": "72148", "quantity": "1", "quantityTypeCode": "UN"}]
quantitystring- Number of units requested, such as visits or days, as a string. Set quantity_type_code too. Example: 3
quantity_type_codestring- Code for the quantity's unit, such as DY (days) or VS (visits).
rendering_providersarray- Providers or facilities that will perform the service. Each item has a roleCode (for example SJ service provider, FA facility, 71 attending physician), name (lastName, firstName), npi, specialtyCode and address fields. Example: [{"roleCode": "SJ", "lastName": "EXAMPLE IMAGING", "npi": "1234567893", "addressLine1": "2 MAIN ST", "city": "JACKSONVILLE", "stateCode": "FL", "zipCode": "32202"}]
service_level_codestring- Level of service code, such as E (elective), U (urgent) or 03 (emergency), when the payer requires it.
service_type_codestring- X12 service type code for the service being reviewed. Examples: 1 (Medical Care), 2 (Surgical), 42 (Home Health Care), 48 (Hospital Inpatient), 69 (Maternity), 73 (Diagnostic Medical), A9 (Rehabilitation). Use configurations_list with type service-reviews for the payer's allowed values.
to_datestring- Service end date or discharge date, as YYYY-MM-DD. Example: 2026-02-03
availity_service_review_updateUpdate an existing prior authorization or referral and send the change to the health plan.WriteUpdate Service Review
Update an existing prior authorization or referral and send the change to the health plan. Returns HTTP 202 with the service review's id, status and statusCode while Availity sends the update, plus any validationMessages. Use service_review_update only when service_review_get shows updatable true, and change only the fields in updatableFields. Poll service_review_get afterwards for the payer's response.
- Idempotent
Inputs
service_reviewobjectrequired- The complete service review to send back, including its id: take the object returned by service_review_get, change only the fields listed in its updatableFields, and pass the whole object. Only reviews with updatable true can be changed. Example: {"id": "12345678", "payer": {"id": "BCBSF"}, "requestTypeCode": "HS", "toDate": "2026-02-10", "renderingProviders": [{"roleCode": "SJ", "lastName": "EXAMPLE IMAGING", "npi": "1234567893"}]}
mock_scenario_idstring- Demo plan only. ID of the canned response scenario Availity's Demo plan should return, sent as the X-Api-Mock-Scenario-ID header. Leave empty on the Standard (production) plan. Valid IDs for this operation: SR-UpdateRequestAccepted-i, SR-UpdateRequestError-i.
availity_service_review_voidVoid (cancel) an existing prior authorization or referral at the health plan.DestructiveVoid Service Review
Void (cancel) an existing prior authorization or referral at the health plan. Returns HTTP 202 with a Location to poll while Availity sends the void request to the payer. Use service_review_void only when service_review_get shows deletable true. Poll service_review_get afterwards to confirm. This cannot be undone.
- Idempotent
Inputs
service_review_idstringrequired- The ID of the service review to void, from service_review_get or service_reviews_search. Example: 12345678
mock_scenario_idstring- Demo plan only. ID of the canned response scenario Availity's Demo plan should return, sent as the X-Api-Mock-Scenario-ID header. Leave empty on the Standard (production) plan. Valid IDs for this operation: SR-DeleteRequestAccepted-i, SR-DeleteRequestError-i.
No tools match.
