目的 |
外部システムからの自動発信やハードフォン利用時にパソコンのCRM側から発信操作を行いたい場合などに利用します。 |
---|---|
対象プラン |
|
用語 |
【コールバック】 BIZTELにおけるコールバックとは、システムからの電話が自動で掛かってくることを指しています。 内線宛にシステムから着信後にお客様へシステムから発信といった動作が可能になります。 (詳細はコールバックAPI機能概要を参照ください。) 【BIZTEL API】 BIZTELとして公開しているAPIとなり、外部システムからBIZTELに対して実行処理や履歴などの取得を行うことができるパラメーターが用意されています。 |
ポイント |
・コールバックAPIに関しては、URLを実行して動作させるタイプと、BIZTELとして公開しているAPI(BIZTEL API)を実行するパターンがあります。 ・BIZTEL APIの実行にはAPIリクエスト数の上限と、連続実行に関する制限があります。 ・本機能をご利用頂く場合、「コールバックAPI」のオプション契約が必須です。 |
・本マニュアルはHTML/PHP(PCRE正規表現等)/WebAPIの基礎的な技術知識がある、WEB系開発者様やCRMベンダー様を対象にしております。
目次
※項目名をクリックいただく事で項目が展開され、参照したい手順へ移動できます。
1. コールバックAPI 機能概要
BIZTELでは、指定した2つの電話番号(BIZTEL内の内線も可能)に対し発信し、該当の二者を通話状態にする事が可能です。
●イメージ図
● コールバックAPIを実行した際の処理の流れ
項番 |
動線 |
---|---|
①httpリクエスト | httpリクエストにて、BIZTEL APIを実行します。 |
②1stコール発信 |
BIZTELサーバから1stコール先に対して、発信を行います。 (例:内線xxxx宛に着信) |
③1stコール応答 |
1stコール先が応答します。 (例:内線xxxxがソフトフォンで応答) |
④2ndコール発信 |
BIZTELサーバから2ndコール先に対して、発信を行います。 (例:外線番号xxxxxxxxxxのお客様へ発信) |
⑤2ndコール応答 |
2ndコール先が応答します。 (例:外線番号xxxxxxxxxxのお客様が応答) |
⑥通話開始 | 1stコール先、2ndコール先での通話が開始されます。 |
2. リクエスト方式
コールバックAPIを実行する際、実行方法が2種類存在します。
認証方式 | HTTPメソッド | URI | 備考 |
---|---|---|---|
画面ログイン方式 | GET | /callback | 画面ログイン方式では、BIZTEL管理画面のログイン画面が表示されます。 ※管理画面にログイン済みの際は、省略されます。 |
APIトークン方式 | POST | /public/api/v1/callback |
外部システムからBIZTEL APIを実行する仕組みになります。 認証のため、APIトークンが必要となります。 |
3. リクエストパラメータ
コールバックAPIで使用するパラメータは以下となります。
パラメータ | 説明 | 備考 |
---|---|---|
first_call_number | 1stコール先の電話番号 |
・外線発信の場合は通知番号プレフィックスが利用可能 (first_caller_numberに値が入っている場合でもプレフィックス値を優先する) ・本パラメータが1stコール履歴の「着信番号」「入力番号」「最終着信番号」になります ・本パラメータが2ndコール履歴の「発信番号」になります |
second_call_number | 2ndコール先の電話番号 |
・外線発信の場合は通知番号プレフィックスが利用可能 (second_caller_numberに値が入っている場合でもプレフィックス値を優先する) ・本パラメータが2ndコール履歴の「着信番号」「入力番号」「最終着信番号」になります ・本パラメータが1stコール履歴の「発信番号」になります |
first_caller_number | 1stコール先への通知番号 |
・first_caller_numberを用いて通知番号を指定していない場合、1stコール時の相手先番号は2ndコール先の番号となります。 ※BIZTELは「管理画面に登録されている&設定済みの番号のみ通知可能」というの仕様であるため、それ以外の番号を指定した場合はBIZTELの仕様に則った番号(システム設定→未設定時の通知番号)を通知します。 ・内線発信の場合は本パラメータを指定していても通知番号設定は無視されます(外線発信時のみ有効) ・本パラメータが1stコール履歴の「通知番号」になります ※より優先度の高い通知番号(プレフィック付き外線発信等)が設定されている場合は、そちらの通知番号が優先されます |
second_caller_number | 2ndコール先への通知番号 |
・second_caller_numberを用いて通知番号を指定していない場合、2ndコール時の相手先番号は1stコール先の番号となります。 ※BIZTELは「管理画面に登録されている&設定済みの番号のみ通知可能」というの仕様であるため、それ以外の番号を指定した場合はBIZTELの仕様に則った番号(システム設定→未設定時の通知番号)を通知します。 ・内線発信の場合は本パラメータを指定していても通知番号設定は無視されます(外線発信時のみ有効) ・本パラメータが2ndコール履歴の「通知番号」になります ※より優先度の高い通知番号(プレフィック付き外線発信等)が設定されている場合は、そちらの通知番号が優先されます |
timeout | 1stコールのタイムアウト時間 |
無指定あるいは0指定時にはデフォルト値(30)が適用されます タイムアウト時間を超過した場合は切断されます |
async_flg | 1stコールの同期フラグ |
同期 = 0, 非同期 = 1 非同期時には1stコール先に発信前にAPIレスポンスを返却する(リクエストを受けた意) 同期時には1stコール先に発信した結果を待ってAPIレスポンスを返却する |
request_code | 発着信履歴のrequest_codeに記録する文字列 | コールバック時に渡したパラメータを保持する。 CRMなどに事前に登録しておいたIDを入れることで、発信とCRMデータを突き合わせる事などが可能になる。 |
memo | 発着信履歴のメモに記録する文字列 | ご自由にご記入ください。 |
Authorization | APIトークン認証方式の際に利用 | Token トークン文字列 |
実行例
画面ログイン方式の実行例 |
---|
■実行例 プラウザのアドレスバーにURLを入力する。 https:// ご契約BIZTELサーバURL :8000/callback?リクエストパラメータ ■入力サンプル https://sxxxxxxxxxxxx.u.biztel.jp:8000/callback?first_call_number=2001&second_call_number=03xxxxxxxx&async_flg=0 ※内線2001宛に着信・応答後、外線03xxxxxxxx宛に発信されます。 また、「async_flg=0」の定義を行っているため、発信が完了したことがブラウザ上で表示されます。 (失敗時には失敗した旨の表示がされます。詳細は下記、4.3 レスポンスボディを参照してください。) |
APIトークン認証方式 |
---|
■実行例 macOSのターミナルにて下記コマンドを入力し、実行する ※本コマンドはcurlコマンドでの一例を記載しています。実行する外部システムにより実行内容は変更してください。 curl -X POST --header 'Content-Type: application/x-www-form-urlencoded' --header 'Accept: application/json' --header 'Authorization: Token ★事前に払い出したAPIトークン★' -d '★リクエストパラメータ★' 'https://★ ご契約BIZTELサーバURL ★:8000/public/api/v1/callback' ■入力サンプル curl -X POST --header 'Content-Type: application/x-www-form-urlencoded' --header 'Accept: application/json' --header 'Authorization: Token cc673fea2227201182aa9261626e08a39cfbb96e7d952bcccb79d31e4f76310e0cf5cd3276f942b9' -d 'first_call_number=2001&second_call_number=03xxxxxxxx &async_flg=0' 'https://sxxxxxxxxxxxx.u.biztel.jp:8000/public/api/v1/callback ※内線2001宛に着信・応答後、外線03xxxxxxxx宛に発信されます。 また、「async_flg=0」の定義を行っているため、発信が完了したことがレスポンスボディに表示されます。 (失敗時には失敗した旨の表示がされます。詳細は下記、4.3 レスポンスボディを参照してください。) |
4. レスポンス
4.1 レスポンスコード
BIZTEL API連携時(トークン認証時)のレスポンスコードは以下となります。
HTTP Status Code | Reason | 説明 |
---|---|---|
200 | Successful Operation | 成功 |
400 | Bad Request | 不正なリクエスト |
401 | Unauthorized | 認証失敗 |
429 | TooManyRequest | バースト上限の超過 |
500 | Internal Server Error | システム障害 |
4.2 ヘッダー
ヘッダー情報は以下となります。
Response Headers |
---|
{ |
4.3 レスポンスボディ
レスポンスボディの例を記載します。
●画面ログイン方式
状況 | 同期・非同期 | Response Body |
---|---|---|
1stコールが成功した場合 | 同期 | |
1stコールが失敗した場合 (着信拒否した場合も含む) |
同期 | |
1stコールが成功した場合 | 非同期 | |
1stコールが失敗した場合 (着信拒否した場合も含む) |
非同期 |
●トークン認証方式
状況 | 同期・非同期 | Response Body |
---|---|---|
1stコールが成功した場合 | 同期 | { "request_id": "20040600000568090005" } |
1stコールが失敗した場合 (着信拒否した場合も含む) |
同期 |
{ "name": "CallbackControlException", "type": "CALL_DECLINED", "exception_id": null, "message": "発信元が応答しませんでした", "messages": [], "reason": null } |
1stコールが成功した場合 | 非同期 | [] |
1stコールが失敗した場合 (着信拒否した場合も含む) |
非同期 | [] |
5. 関連履歴
コールバックAPIに関連する履歴は以下となります。
履歴 | 記録対象 | 備考 |
---|---|---|
発着信履歴 | 1stコールの履歴 2ndコールの履歴 |
コールバック発信の際は1stコールと2ndコールで2件の履歴が記録される コールバック発信の際は発着信履歴のコールバックフラグに情報を記録する request_codeに値を入れている場合はリクエストコードに情報を記録する |
同時通話数履歴 | 1stコールの履歴 2ndコールの履歴 |
コールバック発信の際は1stコールと2ndコールで2件の履歴が記録される ※1通話あたり、同時通話数を2消費しますのでご注意ください。 |
チャネル使用状況 | なし | チャネル使用状況は2消費する。(チャネル使用状況の仕様に準じる) |
課金明細 | なし |
1stおよび2ndに外線番号を指定した場合、それぞれの番号に対し発信を行いますので、それぞれで通話料が発生します。(課金明細の仕様に準じる) ※課金明細ではシステムからの発信となるため、ソフトフォンやハードフォンの内線が表示されませんのでご注意ください。 |
6. エラー仕様
パラメータ | エラー条件 |
---|---|
first_call_number | 未入力 |
登録されている電話端末の内線番号 or BIZTEL登録外の外線番号 以外の値が入力されている場合 | |
発信先が内線番号 & 発信先が通話中の場合 | |
second_call_number | 未入力 |
登録されている電話端末の内線番号 or BIZTEL登録外の外線番号 以外の値が入力されている場合 | |
発信先が内線番号 & 発信先が通話中の場合 | |
first_caller_number | 登録されていない番号を入力した場合 |
second_caller_number | 登録されていない番号を入力した場合 |
timeout | 数値以外が入力されている場合 |
async_flg | 0/1以外の値が入力されている場合 |
request_code | 半角英数字と「_」「-」「.」以外の値が入力されている場合 |
21文字以上が入力されている場合 | |
memo | 半角英数字と「_」「-」「.」以外の値が入力されている場合 |
21文字以上が入力されている場合 | |
Authorization | 未入力 |
認証に失敗した場合 |
7. APIリクエスト数の消費仕様について
コールバックAPIは、認証方式によってAPI消費数が異なります。
認証方式 | ライセンス消費数 | 備考 |
---|---|---|
画面ログイン認証方式 | 消費しない | API処理でない(画面認証を経由して実行している)ためライセンス消費数にはカウントしません。 |
APIトークン認証方式 | 1リクエストにつき、1消費 |
・累積APIリクエスト数、累積APレスポンスオブジェクト数ともに1づつ消費する。 |
8. 制約・その他
● 1stコール先はBIZTELの電話端末(内線番号・ダイヤルイン番号)もしくはBIZTEL登録外の外線が指定可能です。
※BIZTEL内のコールセンターやIVRの内線番号、BIZTELで利用している外線番号は指定することができません。
※BIZTELバージョン 3.2.1 以降、BIZTELで利用している外線番号も指定可能です。
● 1stコール時の不在応答設定・カレンダー・着信ルーティング等は動作しません。
● 内線連携オプションをご利用の場合、内線連携先BIZTELサーバの内線番号は指定できません。
● コールバックAPIでBIZTELと関係のない2つの外線番号が指定された場合、
2ndコール側ではイベントが発生しないため正しくステータスが表示されません。
● IPアクセス制御を有効にしている場合、コールバックAPIを実行する拠点(またはサーバ)のIPアドレスが登録されていないと通信がブロックされるため、事前に対象のIPアドレスをIPアクセス制御に設定してください。
● BIZTELバージョン 3.4.10 以降コールバックAPIを用いた国際発信が制限されています。
ご要望の場合は、弊社窓口までご連絡ください。
● コールバック発信の履歴については、発着信履歴・コールセンター履歴に記録されます。
※コールバック発信時には必ず「ログオフ」以外の状態で発信を行って下さい。
(「ログオフ」の場合、コールセンター履歴に記録されずレポートでも確認できません。)
発信履歴上の見え方
発着信履歴では、コールバック発信1件につき2行の履歴が記録されます。
次の履歴表示の例では、下の行(赤枠)が1stコール(自分のコールバック先への発信)、上の行(青枠)が2ndコール(通話相手への発信)の履歴となります。
※スーパバイザロールで発着信履歴を参照する場合、該当の履歴に用いられた通知番号に対してのリソース権限を付与する必要があります。
※リソース権限の詳細は「1.権限(ロールとリソース)の設定」を参照ください。
※BIZTELバージョン 3.7.0 以降、1stコール(自分のコールバック先への発信)の履歴には、録音データ、音声認識連携のテキストデータは紐づきませんのでご注意ください。
コールセンター履歴での見え方
コールセンター履歴では、コールバック発信は「アウトバウンド切断」として記録されます。
※スーパバイザロールでコールセンター履歴を参照する場合、該当のコールセンターに対してのリソース権限を付与する必要があります。
※リソース権限の詳細は「1.権限(ロールとリソース)の設定」を参照ください。