import { BaseConnector } from '../../base/base.connector';
import type { ISmsOptions, ISmsProvider, ISendMessageSuccessResponse, WithPassthrough, SmsSendResult, ISmsConnector } from '../../types';
import { ChannelTypeEnum } from '../../types';
import type { InfobipConfig } from './infobip.config';
import type { InfobipNarrowedInput } from './infobip.types';
export declare class InfobipSmsConnector extends BaseConnector implements ISmsProvider, ISmsConnector {
    private config;
    readonly id = "infobip";
    readonly channelType: ChannelTypeEnum.SMS;
    constructor(config: InfobipConfig, fetchImpl?: typeof fetch);
    /**
     * Thinwrap-native send. Implements `ISmsConnector`.
     * Builds a JSON body and POSTs to the per-account endpoint
     * `https://<baseUrl>/sms/2/text/advanced`. Authenticates with Infobip's
     * custom `Authorization: App <apiKey>` scheme (not Bearer, not Basic).
     *
     * Infobip wire keys are camelCase (`callbackData`, `notifyUrl`,
     * `validityPeriod`, `bulkId`, `sendAt`, `messageId`);
     * these are written explicitly in the `connectorBody` literal rather than
     * invoking a casing transform.
     *
     * The endpoint answers HTTP 200 even when it refuses the message outright:
     * the per-message `status` then carries group 5 (REJECTED), which is
     * surfaced as a `ConnectorError` rather than a success.
     *
     * Infobip's v2 advanced endpoint takes a `messages: [...]` array even for
     * one message; each message has `destinations: [{ to }]`. The connector
     * wraps `[input.to]` automatically. Multi-recipient batches are out of v1.0
     * Thinwrap baseline — consumers can override
     * `_passthrough.body.messages`.
     */
    send(input: InfobipNarrowedInput): Promise<SmsSendResult>;
    /**
     * Body-layer mapping: HTTP 200 whose message status is in group 5
     * (REJECTED). The status `name` says why: destination / prefix / missing
     * recipient / DND / not-registered rejections are recipient problems,
     * `REJECTED_FLOODING_FILTER` is throttling, and everything else (sender,
     * credits, …) is a request the caller must change.
     */
    private mapRejectedStatus;
    /**
     * Map Infobip error responses to canonical `ConnectorError` with the 6-value
     * `ProviderCode` union. Parses `Retry-After`:
     * parsed seconds embedded in `providerMessage` text; raw header
     * value on `cause.retryAfter`. No structured `retryAfterSeconds` field per
     * Retry is consumer policy (no retryAfterSeconds field).
     *
     * Infobip's body error shape is
     * `{ requestError: { serviceException: { messageId, text } } }`. The
     * `EC_*` `messageId` (e.g., `EC_INVALID_DESTINATION_ADDRESS`) is preserved
     * on `cause.raw` but not individually mapped — HTTP status drives the
     * canonical mapping.
     */
    private mapVendorError;
    sendMessage(options: ISmsOptions, bridgeProviderData?: WithPassthrough<Record<string, unknown>>): Promise<ISendMessageSuccessResponse>;
}