Veterinary and Pharmacy Integrations

This guide covers building integrations for the veterinary and pharmacy programs: consult booking, referrals to practices, and prescription fulfillment support. One rule shapes every step: veterinary medicine is licensed and regulated by state law, and the Platform is not a veterinary practice. The API carries scheduling, payment, and program data; it does not authorize the practice of veterinary medicine and does not hold clinical records. State law governs the veterinarian-client-patient relationship (VCPR) and prescription dispensing, as stated in the veterinary and pharmacy instruments in Veterinary and Pharmacy, and no integration may present the Platform's rules as permission to do anything a state forbids. Endpoint detail is in Veterinary and Pharmacy Endpoints.

Goal and prerequisites

Goal: an integration that makes licensed work easier to schedule, refer, and pay for: while clinical judgment, clinical records, and dispensing decisions stay with the licensed professionals and their own systems.

Prerequisites: participation in the veterinary or pharmacy program under Veterinary and Pharmacy, an API key scoped to that program, and: before any consult flow is built: a working VCPR check (below). If your organization cannot state, per state you will operate in, what the VCPR rules require, stop and settle that first with your own counsel; the API cannot settle it for you.

Consult booking: the VCPR gate comes first

Build booking and consult flows in this order

1. Run the VCPR check before scheduling, not after. A virtual consult requires a valid VCPR as the applicable state's law defines it. In some states a VCPR cannot be established by electronic means alone: Tennessee is one (Tennessee Code Annotated §63-12-103): so a new client in such a state is booked in person first, and virtual consults are offered as follow-ups for existing patients, as the instruments in Veterinary and Pharmacy state.
2. Collect the attestation the flow requires: for example, that an in-person examination occurred within the period the state requires: and record it with the booking. The record is the audit trail; a consult booked without it is a compliance defect, not a paperwork gap.
3. Apply the state's prescription rules at booking time. What a veterinarian may prescribe on a virtual relationship varies by state; the consult flow reads the applicable rule for the client's state rather than assuming one national answer.
4. Keep teletriage distinct. General pet-care information and urgency guidance require no VCPR: but the moment an interaction becomes a specific animal's diagnosis or treatment, it is a consult, and the gate applies. Your integration must never label triage output as a diagnosis.

What the integration handles: and what it never handles

The Platform's consult surface is scheduling and session logistics

• Booking, rescheduling, reminders, and payment for consults.
• The consultation session itself, conducted by the licensed veterinarian.
• Scheduling and session metadata on the Platform side.

Clinical information: examination findings, diagnoses, treatment plans, clinical notes: belongs in the veterinarian's own practice system, not in your integration and not in any field the API accepts. If a design you are reviewing proposes storing clinical detail in product notes, order comments, or custom fields "temporarily," stop the design: there is no compliant version of it. Data minimization for this program is stated in Security and Compliance.

Referrals

The Platform maintains a directory of veterinary practices for owner referrals

1. Routing follows urgency and geography: emergency presentations go to emergency practices; routine needs go to suitable nearby practices. Your integration supplies accurate location and urgency information and lets the directory do the routing.
2. A referral is sent only when delivery is confirmed. Build the hand-off so a failed delivery is visible and retried or escalated: never presented to the owner as sent when it was not.
3. Keep the two pipelines separate. Sending owners to practices (referrals) and recruiting practices to the directory (program enrollment) are different flows with different data and different rules. Do not merge them.
4. Compensation around referrals carries legal risk. Payment structures tied to referral volume raise regulatory issues that vary by state. The structures the program treats as acceptable are flat directory or marketing fees untied to lead volume, program fees, or referrals carried within consult revenue: as Veterinary and Pharmacy states. If your integration moves money around referrals in any other shape, have the structure reviewed by counsel before it ships, not after.

Pharmacy

Prescription fulfillment through the program follows the same shape as the consult surface

1. The veterinarian's prescription is the authority. Dispensing requires a valid prescription from a licensed veterinarian, verified before fulfillment begins.
2. The state rules govern what may be dispensed on the relationship the prescription rests on; a prescription valid for in-person dispensing is not automatically valid for every dispensing channel.
3. The pharmacy fulfills against the verified prescription only: product, quantity, and refills as prescribed, nothing substituted on commercial grounds.

Keep pharmacy products distinct from the ordinary supplement and wellness catalog in your integration's data and displays. They sit in different regulatory categories, carry different obligations, and must never be merchandised as interchangeable.

Failure handling

• VCPR check fails or cannot be completed: do not book the virtual consult. Offer the in-person path. Never retry-loop the check hoping for a different answer, and never let an operator override it in your tooling.
• A referral delivery fails: the owner sees an honest state ("not yet sent"), the failure is logged with its cause, and the referral is completed by retry or by staff follow-up.
• Prescription verification fails: fulfillment stops. The integration reports the failure to the parties who can cure it (the prescribing practice, the pharmacy) and takes no partial action against an unverified prescription.
• State rules you have not implemented: treat as out of scope, not as permitted. An integration that operates in a state whose rules it has not encoded is operating unlicensed by default.

What to build

• Booking flows: VCPR gate first, scheduling second, attestation recorded, reminders and payment through the standard resources.
• Practice-facing tooling: consult schedules, session access, referral inboxes with confirmed delivery: and no clinical record-keeping anywhere in it.
• Owner-facing flows: honest urgency guidance, clear next steps, and bookings that never promise a service the client's state does not allow.

Veterinary integrations carry a professional's license on the other end of them. Build so the licensed work is possible, the unlicensed work is impossible, and the record proves which was which.

Questions about a veterinary or pharmacy integration: support@aapawz.com.