> **Building with AI coding agents?** Install the authstack plugin with one command. This equips your agent with accurate Scalekit implementation patterns. > > **Recommended** (the `-y` flags skip prompts, so the command runs without an interactive terminal): > ```bash > npx -y @scalekit-inc/cli setup -y > ``` > > Global: > ```bash > npm install -g @scalekit-inc/cli > scalekit setup -y > ``` > > Supports Claude Code, Cursor, GitHub Copilot, Codex + skills for other Agent Skills-compatible agents in `~/.agents/skills`. > Skills: integrate-agentkit, implement-saaskit, add-mcp-oauth, implement-sso, implement-scim. > [Full setup guide](https://docs.scalekit.com/dev-kit/build-with-ai/) --- # Connect AI agents to Availity 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. **Authentication:** OAuth 2.0 Client Credentials **Categories:** Healthcare **Tools:** 11: 8 read, 2 write, 1 destructive **Users sign in with:** Service account **Built by:** Scalekit connector **Try it:** [Playground in the Scalekit dashboard](https://app.scalekit.com/ws/signup?sk_intent=playground&provider=AVAILITY) ## Setup 1. ### Install the SDK **Node.js** ```bash npm install @scalekit-sdk/node dotenv ``` **Python** ```bash pip install scalekit-sdk-python python-dotenv ``` 2. ### Set your credentials Add your Scalekit credentials to your `.env` file. Find values in **[app.scalekit.com](https://app.scalekit.com)** > **Developers** > **API Credentials**. ```sh title=".env" SCALEKIT_ENVIRONMENT_URL= SCALEKIT_CLIENT_ID= SCALEKIT_CLIENT_SECRET= ``` 3. ### Create the Availity connection In **AgentKit > Connections**, create an Availity connection. The name you give it is the `connection_name` your code passes. See [Configure connections](/agentkit/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. 1. ### 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. 2. ### Create the connection In the [Scalekit dashboard](https://app.scalekit.com), 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 the `connection_name` your code passes. 3. ### 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. > note: Demo plan responses > > On the free Demo plan, Availity returns canned responses whatever the request. To pick a scenario, set the tool's optional `mock_scenario_id` input, such as `Coverages-Complete-i`. ## Tools Pass the exact name to `execute_tool`, with an input like each tool's example. To ask for a tool that's missing, use the [request form](https://scalekitsupport.portal.usepylon.com/forms/request-a-connector-tool). **Node.js** ```typescript const result = await actions.executeTool({ toolName: 'availity_claim_status_get', toolInput: { claim_status_id: '', }, connector: 'availity', identifier: 'user_123', }) ``` **Python** ```python result = actions.execute_tool( tool_name="availity_claim_status_get", tool_input={ "claim_status_id": "", }, connection_name="availity", identifier="user_123", ) ``` `result.data` is the app's response as JSON, and `result.execution_id` (`executionId` in Node.js) is the ID of the call. ### `availity_claim_status_get` Get Claim Status · Read-only 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. Read only: yes. Destructive: no. Idempotent (safe to retry): yes. Inputs: - `claim_status_id` (`string`, required): The claim status ID returned by claim_statuses_search (the id field of a claimStatuses item). Example: 5334032768852043884 Example input: `{"claim_status_id":""}` ### `availity_claim_statuses_search` Check Claim Status · Read-only 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. Read only: yes. Destructive: no. Idempotent (safe to retry): yes. Inputs: - `payer_id` (`string`, required): Availity-specific identifier of the health plan that processed the claim, from payers_list. Example: BCBSF - `claim_amount` (`string`, optional): Total charge amount on the claim, as a decimal string. Example: 150.00 - `claim_number` (`string`, optional): The health plan's claim tracking number assigned when the claim was received. Example: CLM0001 - `facility_type_code` (`string`, optional): 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_code` (`string`, optional): Claim frequency type code (X12 code source 235), such as 1 (original claim) or 7 (replacement). - `from_date` (`string`, optional): First date of service on the claim, as YYYY-MM-DD. Example: 2026-01-05 - `patient_account_number` (`string`, optional): The provider's own account or reference number for the patient, as sent on the claim. Example: ACCT-0001 - `patient_birth_date` (`string`, optional): The patient's date of birth as YYYY-MM-DD. Example: 1980-01-01 - `patient_first_name` (`string`, optional): The patient's first name. Example: SAMPLE - `patient_gender_code` (`string`, optional): The patient's gender code: F (female) or M (male). One of: `F`, `M`. - `patient_last_name` (`string`, optional): The patient's last name, when the patient is not the subscriber. Example: TESTPATIENT - `patient_subscriber_relationship_code` (`string`, optional): X12 837 individual relationship code of the patient to the subscriber, such as 18 (self), 01 (spouse) or 19 (child). - `payer_assigned_provider_id` (`string`, optional): The health plan-assigned ID of the service provider. Example: P12345 - `provider_first_name` (`string`, optional): First name of the service provider, when the provider is a person. Example: ALEX - `provider_last_name` (`string`, optional): Last name or business name of the service provider on the claim. Example: EXAMPLE CLINIC - `provider_npi` (`string`, optional): The service provider's 10-digit NPI. Example: 1234567893 - `provider_tax_id` (`string`, optional): The service provider's 9-digit tax ID with no dashes. Example: 123456789 - `submitter_first_name` (`string`, optional): First name of the claim submitter, when the submitter is a person. Example: ALEX - `submitter_id` (`string`, optional): The submitter's identifier, for health plans that require it. Example: G12345 - `submitter_last_name` (`string`, optional): Last name or business name of the claim submitter. Example: EXAMPLE CLINIC - `subscriber_first_name` (`string`, optional): The subscriber's first name. Example: SAMPLE - `subscriber_last_name` (`string`, optional): The subscriber's last name. Example: TESTPATIENT - `subscriber_member_id` (`string`, optional): The subscriber's health plan member ID. Example: ABC123456789 - `to_date` (`string`, optional): Last date of service on the claim, as YYYY-MM-DD. Example: 2026-01-05 Example input: `{"payer_id":""}` ### `availity_configurations_list` List Payer Configurations · Read-only 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. Read only: yes. Destructive: no. Idempotent (safe to retry): yes. Inputs: - `type` (`string`, required): 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: `270`, `service-reviews`, `service-reviews-inquiry`, `claim-statuses-inquiry`, `professional-claims`, `institutional-claims`, `enhanced-claim-status`. - `limit` (`integer`, optional): Maximum number of configurations to return, from 1 to 50. Default 50. - `offset` (`integer`, optional): Zero-based index of the first configuration to return, for paging. Default 0. - `payer_id` (`string`, optional): Availity payer ID whose rules you want. Leave empty to list every payer that supports the transaction type. Example: BCBSF - `subtype_id` (`string`, optional): 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. Example input: `{"type":"270"}` ### `availity_coverage_create` Check Eligibility and Benefits · Read-only 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. Read only: yes. Destructive: no. Idempotent (safe to retry): no. Inputs: - `payer_id` (`string`, required): Availity-specific identifier of the patient's health plan, from payers_list. Example: BCBSF - `service_type` (`string`, required): 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_date` (`string`, optional): Date of service to check coverage for, as YYYY-MM-DD. Defaults to today at the health plan. Example: 2026-01-15 - `card_issue_date` (`string`, optional): Issue date on the member's health plan card, as YYYY-MM-DD, for plans that require it. Example: 2025-01-01 - `group_number` (`string`, optional): The patient's health plan group number. Example: GRP12345 - `medicaid_id` (`string`, optional): The patient's Medicaid ID number, for Medicaid plans. Example: 123456789012 - `member_id` (`string`, optional): The patient's or subscriber's health plan member ID as printed on the card. Example: ABC123456789 - `mock_scenario_id` (`string`, optional): 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_date` (`string`, optional): The patient's date of birth as YYYY-MM-DD. Most health plans require it. Example: 1980-01-01 - `patient_first_name` (`string`, optional): The patient's first name. Example: SAMPLE - `patient_gender` (`string`, optional): The patient's gender code: M (male), F (female) or U (unknown). One of: `M`, `F`, `U`. - `patient_last_name` (`string`, optional): The patient's last name. Example: TESTPATIENT - `patient_middle_name` (`string`, optional): The patient's middle name or initial. Example: Q - `patient_state` (`string`, optional): Two-letter code of the patient's state of residence, for plans that require it. Example: FL - `patient_suffix` (`string`, optional): The patient's name suffix. Example: JR - `payer_assigned_provider_id` (`string`, optional): An identifier the health plan assigned to the requesting provider, for plans that accept one. Example: P12345 - `place_of_service` (`string`, optional): Place of service code, for health plans that require it (X12 code source 237). Example: 11 (office) - `procedure_code` (`string`, optional): Procedure code to check benefits for, such as a CPT or HCPCS code, for plans that support procedure-level inquiries. Example: 99213 - `provider_city` (`string`, optional): The requesting provider's city, for health plans that require it. Example: JACKSONVILLE - `provider_first_name` (`string`, optional): The requesting provider's first name, when the provider is a person. Example: ALEX - `provider_last_name` (`string`, optional): The requesting provider's last name or organization name. Example: EXAMPLE CLINIC - `provider_npi` (`string`, optional): The requesting provider's 10-digit National Provider Identifier. Most health plans require it. Example: 1234567893 - `provider_specialty` (`string`, optional): The requesting provider's specialty as an X12 provider taxonomy code (code source 682). Example: 207Q00000X - `provider_state` (`string`, optional): The requesting provider's two-letter state code, for health plans that require it. Example: FL - `provider_tax_id` (`string`, optional): The requesting provider's 9-digit tax ID with no dashes, for health plans that require it. Example: 123456789 - `provider_zip_code` (`string`, optional): The requesting provider's ZIP code, for health plans that require it. Example: 32202 - `submitter_id` (`string`, optional): A payer-assigned submitter identifier, for health plans that require it. Example: G12345 - `subscriber_relationship` (`string`, optional): 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: `18`, `01`, `19`, `G8`. - `to_date` (`string`, optional): End date of the coverage period to check, as YYYY-MM-DD, for health plans that support a date range. Example: 2026-01-31 Example input: `{"payer_id":"","service_type":""}` ### `availity_coverage_get` Get Eligibility and Benefits · Read-only 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. Read only: yes. Destructive: no. Idempotent (safe to retry): yes. Inputs: - `coverage_id` (`string`, required): The coverage response ID returned by coverage_create (the id field). Example: 7276849100383928590 - `mock_scenario_id` (`string`, optional): 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. Example input: `{"coverage_id":""}` ### `availity_payers_list` List Payers · Read-only 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. Read only: yes. Destructive: no. Idempotent (safe to retry): yes. Inputs: - `availability` (`string`, optional): Filter by contract requirement: available returns payers that do not need an additional Availity contract, contractrequired returns payers that do. One of: `available`, `contractrequired`. - `enrollment_required` (`boolean`, optional): 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_id` (`string`, optional): Availity-specific payer identifier to look up a single payer. Leave empty to list every payer on your contract. Example: BCBSF - `submission_modes` (`array`, optional): Only return payers that accept the transactions through these submission methods: Portal, Batch, RealTime or API. Example: ["API"] - `transaction_types` (`array`, optional): 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"] Example input: `{}` ### `availity_service_review_get` Get Service Review · Read-only 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. Read only: yes. Destructive: no. Idempotent (safe to retry): yes. Inputs: - `service_review_id` (`string`, required): The service review ID returned by service_review_create or service_reviews_search (the id field). Example: 12345678 - `mock_scenario_id` (`string`, optional): 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). Example input: `{"service_review_id":""}` ### `availity_service_reviews_search` Search Service Reviews · Read-only 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. Read only: yes. Destructive: no. Idempotent (safe to retry): yes. Inputs: - `certification_issue_date` (`string`, optional): Date the authorization certification was issued, as YYYY-MM-DD. Example: 2026-02-01 - `certification_number` (`string`, optional): Number the health plan assigned once the authorization was certified. Example: 1231723 - `from_date` (`string`, optional): Service beginning date, as YYYY-MM-DD. Example: 2026-02-01 - `mock_scenario_id` (`string`, optional): 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_date` (`string`, optional): The patient's date of birth as YYYY-MM-DD. Example: 1980-01-01 - `patient_first_name` (`string`, optional): The patient's first name. Example: SAMPLE - `patient_last_name` (`string`, optional): The patient's last name. Example: TESTPATIENT - `patient_subscriber_relationship_code` (`string`, optional): Patient's relationship to the subscriber: 18 (self), 01 (spouse), 19 (child) or G8 (other). One of: `18`, `01`, `19`, `G8`. - `payer_id` (`string`, optional): Availity-specific identifier of the patient's health plan. Example: BCBSF - `reference_number` (`string`, optional): Number the health plan assigned to a submitted request while under review; often called the case or authorization number. Example: REF12345 - `request_type_code` (`string`, optional): Type of review to search: HS (outpatient authorization), AR (inpatient admission review) or SC (referral). One of: `HS`, `AR`, `SC`. - `requesting_provider_first_name` (`string`, optional): The requesting provider's first name. Example: ALEX - `requesting_provider_last_name` (`string`, optional): The requesting provider's last or business name. Example: EXAMPLE CLINIC - `requesting_provider_npi` (`string`, optional): The requesting provider's 10-digit NPI. Example: 1234567893 - `requesting_provider_specialty_code` (`string`, optional): The requesting provider's taxonomy code (X12 code source 682). Example: 207Q00000X - `requesting_provider_submitter_id` (`string`, optional): The requesting provider's payer-specific submitter ID. Example: G12345 - `requesting_provider_tax_id` (`string`, optional): The requesting provider's tax ID, no dashes. Example: 123456789 - `session_id` (`string`, optional): 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_code` (`string`, optional): Only return reviews with this status code, for example A1 (Certified in Total) or A4 (Pended). - `subscriber_first_name` (`string`, optional): The subscriber's first name. Example: SAMPLE - `subscriber_last_name` (`string`, optional): The subscriber's last name. Example: TESTPATIENT - `subscriber_member_id` (`string`, optional): The subscriber's health plan member ID. Example: ABC123456789 - `to_date` (`string`, optional): Service end date, as YYYY-MM-DD. Example: 2026-02-28 Example input: `{}` ### `availity_service_review_create` Create Service Review · Write 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. Read only: no. Destructive: no. Idempotent (safe to retry): no. Inputs: - `patient` (`object`, required): 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"} - `payer` (`object`, required): The patient's health plan. Needs the Availity payer id; name is optional. Example: {"id": "BCBSF", "name": "FLORIDA BLUE"} - `request_type_code` (`string`, required): Type of review: HS (Health Services Review, outpatient authorization), AR (Admission Review, inpatient authorization) or SC (Specialty Care Review, referral). One of: `HS`, `AR`, `SC`. - `requesting_provider` (`object`, required): 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"} - `subscriber` (`object`, required): The health plan subscriber: memberId, plus firstName and lastName and any address fields the payer requires. Example: {"memberId": "ABC123456789", "firstName": "SAMPLE", "lastName": "TESTPATIENT"} - `additional_fields` (`object`, optional): 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_code` (`string`, optional): Inpatient admissions only: admission source code, such as 1 (physician referral) or 4 (transfer from a hospital). - `admission_type_code` (`string`, optional): Inpatient admissions only: admission type code (X12 code source 231), such as 1 (emergency), 2 (urgent) or 3 (elective). - `diagnoses` (`array`, optional): 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_date` (`string`, optional): Service or admission start date, as YYYY-MM-DD. Example: 2026-02-01 - `mock_scenario_id` (`string`, optional): 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_code` (`string`, optional): Place of service code (X12 code source 237 for professional, 236 for institutional). Examples: 11 (office), 21 (inpatient hospital), 22 (outpatient hospital). - `procedures` (`array`, optional): 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"}] - `quantity` (`string`, optional): Number of units requested, such as visits or days, as a string. Set quantity_type_code too. Example: 3 - `quantity_type_code` (`string`, optional): Code for the quantity's unit, such as DY (days) or VS (visits). - `rendering_providers` (`array`, optional): 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_code` (`string`, optional): Level of service code, such as E (elective), U (urgent) or 03 (emergency), when the payer requires it. - `service_type_code` (`string`, optional): 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_date` (`string`, optional): Service end date or discharge date, as YYYY-MM-DD. Example: 2026-02-03 Example input: `{"patient":{"firstName":"SAMPLE","lastName":"TESTPATIENT","birthDate":"1980-01-01","genderCode":"F","subscriberRelationshipCode":"18"},"payer":{"id":"BCBSF","name":"FLORIDA BLUE"},"request_type_code":"HS","requesting_provider":{"lastName":"EXAMPLE CLINIC","npi":"1234567893","specialtyCode":"207Q00000X","addressLine1":"1 MAIN ST","city":"JACKSONVILLE","stateCode":"FL","zipCode":"32202","contactName":"FRONT DESK","phone":"5555550100"},"subscriber":{"memberId":"ABC123456789","firstName":"SAMPLE","lastName":"TESTPATIENT"}}` ### `availity_service_review_update` Update Service Review · Write 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. Read only: no. Destructive: no. Idempotent (safe to retry): yes. Inputs: - `service_review` (`object`, required): 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_id` (`string`, optional): 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. Example input: `{"service_review":{}}` ### `availity_service_review_void` Void Service Review · Destructive 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. Read only: no. Destructive: yes. Idempotent (safe to retry): yes. Inputs: - `service_review_id` (`string`, required): The ID of the service review to void, from service_review_get or service_reviews_search. Example: 12345678 - `mock_scenario_id` (`string`, optional): 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. Example input: `{"service_review_id":""}` ## Related Other Healthcare & life sciences connectors ([all 16](/agentkit/connectors/?category=healthcare)): - [Synapse MCP server](/agentkit/connectors/synapsemcp/): Vendor MCP, OAuth, 48 tools - [Healthie](/agentkit/connectors/healthie/): Scalekit connector, API key, 44 tools - [Scite MCP server](/agentkit/connectors/scitemcp/): Vendor MCP, OAuth, 25 tools --- ## More Scalekit documentation | Resource | What it contains | When to use it | |----------|-----------------|----------------| | [/llms.txt](/llms.txt) | Structured index with routing hints per product area | Start here — find which documentation set covers your topic before loading full content | | [/llms-full.txt](/llms-full.txt) | Complete documentation for all Scalekit products in one file | Use when you need exhaustive context across multiple products or when the topic spans several areas | | [sitemap-0.xml](https://docs.scalekit.com/sitemap-0.xml) | Full URL list of every documentation page | Use to discover specific page URLs you can fetch for targeted, page-level answers |