<п>Препродаја или уграђивање приступа АИ АПИ-ју није само питање прослеђивања захтева добављачу модела. Прави оперативни рад почиње када сваком даљем кориснику буду потребни сопствени акредитиви, ограничења, евиденција о коришћењу, догађаји наплате, контроле подршке и ревизијски траг. АПИ за партнере или препродавце постоји за управљање том контролном равни.<п>За агенције, консултанте, креаторе СааС-а, панеле препродавача и интерне тимове платформе, АПИ партнера се налази изнад АПИ-ја за закључивање. АПИ за закључивање покреће довршавање ћаскања, уграђивање, генерисање слика, транскрипцију или друге позиве модела. Партнерски АПИ управља пословним објектима око тих позива: клијентима, АПИ кључевима, групама кључева, контролама потрошње, историјом захтева, трансакцијама стања, асинхронизованим пословима, повратним позивима и стањем налога.<п>Ово је важно јер је са дељеним кључем добављача лако започети и са њим је тешко преживети. Када више клијената користи исти акредитив, приписивање постаје крхко. Одговор на злостављање утиче на све. Ограничења стопа и биланси су обједињени. Спорове око наплате је тешко истражити. За подешавање отпорног препродавца потребан је приступ клијента и књига која може да објасни шта се догодило, ко је то изазвао, колико кошта и које контроле су примењене.<х2>Шта би АПИ партнера требало да уради<п>Партнерски АПИ је административни интерфејс између сервера за поуздане системе. Не би требало да буде изложен директно прегледачима, мобилним апликацијама, додацима или непоузданом корисничком коду. Ваш бацкенд, панел за обезбеђивање, радник за наплату, Телеграм бот, конзола за подршку или портал за препродаваче позива АПИ партнера да би креирао и управљао низводним приступом.<п>У контексту АИ мрежног пролаза, АПИ партнера треба да подржава најмање четири трајне одговорности. Прво, требало би да обезбеди акредитиве за клијента. Друго, требало би да организује те акредитиве у групе, планове, пројекте или границе закупца. Треће, требало би да открије евиденцију о употреби и трансакцијама која може да храни системе за наплату и подршку. Четврто, требало би да обезбеди операције животног циклуса као што су замрзавање, одмрзавање, ротирање, померање и брисање кључева.<п>Модел Гате је пример овог обрасца. Његов Партнерски АПИ је документован као интерфејс сервер-сервер за ботове, панеле препродавача, интерне системе за обезбеђивање и поуздане интеграције. Користи аутентификацију носиоца помоћу АПИ кључа партнера и излаже операције за АПИ кључеве, групе, коришћење кључева и група, недавне записе захтева, трансакције стања и асинхронизовано испитивање резултата. То су могућности контролне равни, а не крајње тачке закључивања модела.<п>Разлика је важна. Купци могу да виде једноставну површину производа као што је портал препродавача АИ АПИ-ја, АИ АПИ пакет са белим етикетама или интеграција АИ којом управља агенција. Иза те површине, партнерском систему је потребна довољна структура да креира акредитиве, примени правила плана, потрошњу мерача и управља догађајима подршке без тражења од сваког клијента да креира налоге директног добављача.<х2>Када агенцијама и СааС тимовима затреба један<п>Партнерски АПИ постаје неопходан када је приступ вештачкој интелигенцији део производа или управљане услуге, а не интегрисана услуга. Агенцијама ће можда бити потребан АИ АПИ за агенције тако да сваки клијент има посебан буџет, посебан извештај о коришћењу и посебан прекидач за укидање. СааС компанијама ће можда бити потребни кључеви по закупцу, чак и ако их крајњи корисници никада не виде, тако да платформа може да припише цену модела правом налогу. Тимовима интерне платформе ће можда бити потребне границе на нивоу пројекта за одељења, окружења или апликације.<п>Требало би да размотрите АПИ за препродаваче или партнере ако вам је потребно обезбеђивање кључа за АПИ за клијенте, ограничења потрошње заснована на плану, аналитика делегиране употребе или аутоматска суспензија и ротација. Такође бисте то требали узети у обзир када клијенти купују приступ од вас, а не директно од добављача основног модела. У том случају, однос са клијентима, фактура, путања подршке и примена прихватљиве употребе припадају делимично или у потпуности вашем производу.<п>Налози директних добављача и даље могу бити прави избор за неке клијенте. Они дају купцу директну контролу добављача и јасне фактуре добављача. Али они отежавају обједињену наплату од препродавача, чврста ограничења на нивоу корисника, тријажу подршке и преносивост модела. АПИ-ји администратора добављача могу да излажу пројекте, радне просторе, АПИ кључеве, буџете или извештаје, али ти објекти нису увек еквивалентни међу добављачима. Партнерски АПИ изнад мрежног пролаза са више модела даје вам нормализовани слој за уговор са клијентом.<х2>Основни модел података<п>Издржљива интеграција партнера почиње јасним локалним моделом података. У најмању руку, дефинишите кориснички налог, спољни ИД клијента, план, начин обрачуна, АПИ кључеве, групе кључева, ограничења коришћења, дозволе модела, тренутно стање и метаподатке подршке. Немојте претпостављати да су власник налога, власник обрачуна, налогодавац акредитива, закупац клијента и крајњи корисник исти идентитет.У окружењима препродавача и СааС-а, они се често разликују.<п>Практични модел често укључује ове објекте:<ул><ли><стронг>Купац или закупац: комерцијална или апликација граница која се користи за приписивање и наплату.<ли><стронг>АПИ кључ:акредитив који користи клијент, апликација, окружење или интерни АПИ за позивање<стронг> АПИ-ја. граница: контејнер за дељена ограничења, дозволе модела, правила о ценама или извештавање.<ли><стронг>Запис о коришћењу: нормализовани догађај који описује ИД захтева, клијента, кључ, групу, модел, крајњу тачку, број токена, статус, временску ознаку и компоненте трошкова.<ли><стронг>Контрола стања, трансакција за рефундирање, кредитна трансакција, прилагођавање финансијских трансакција: поравнања.<ли><стронг>Асинхронизовани посао: послат задатак модела који се може завршити касније и треба му испитивање, руковање повратним позивом и коначно стање наплате.<ли><стронг>Догађај ревизије: интерни запис обезбеђивања, промене ограничења, ротације кључева, суспензије, радњи подршке и исхода усаглашавања.<х2>Ток рада обезбеђивања<п>Провизија треба да се третира као машина стања, а не као једна најбоља скрипта. Типичан ток посла почиње креирањем или мапирањем клијента у вашем систему, одабиром плана, креирањем кључа мрежног пролаза са опсегом, додељивањем кључа групи, применом ограничења и дозвола модела, безбедним складиштењем само враћене тајне и испоруком приступа преко одобреног канала.<п>Корисна стања укључују <цоде>на чекању, <цоде>и>кеи> <цоде>лимитс_апплиед, <цоде>испоручено, <цоде>активно, <цоде>суспендовано, <цоде>ротатион_рекуиред и <цоде>избрисано. Ова стања чине покушаје и акције подршке разумљивим. Ако креирање кључа успе, али ограничи време за доделу, систем треба да зна где да настави. Ако корисник надогради са припејд кредита на постпаид фактурисање, систем треба да забележи које су контроле промењене и када.<п>Управљање акредитивима заслужује посебну пажњу. Тајна испорука АПИ кључа треба да буде једнократни безбедан догађај. Не бележите тајне. Немојте слати акредитиве провајдера у прегледаче корисника или мобилне апликације. Чувајте само оно што је потребно за подршку клијенту и обезбедите путање ротације које омогућавају покретање и старих и нових кључева током планираног пресека када производна радна оптерећења зависе од њих.<п>За шири дизајн акредитива, кључеви мрежног пролаза у опсегу корисника би требало да буду део веће <а хреф="/ен/топицс/апи-кеи-манагемент-аи-кеи-манагемент-аи-апис стратегије, бесплатно управљање кључевимастратегијом за управљање кључевима, бесплатно управљање кључевима/. најмање привилегија, одвајање окружења и видљивост подршке.<х2>Идемпотенција је карактеристика наплате<п>Идемпотенција није само финоћа АПИ-ја. У партнерској АПИ аутоматизацији, штити клијенте и финансијске системе од дуплих нежељених ефеката. Прављење кључа двапут, додавање кредита два пута или примена конфликтних ограничења после истека времена може да произведе стварни утицај на клијента.<п>Мутирање операција партнера би требало да захтева стабилне кључеве идемпотенције. Модел Гате документује ово очекивање за мутирајуће захтеве за ПОСТ, ПАТЦХ и ДЕЛЕТЕ Партнер АПИ и упућује имплементаторе да поново покушају исту логичку операцију са истим кључем идемпотенције након истека времена. Такође документује седмодневни период задржавања за евиденцију идемпотенције.<п>Кључ би требало да буде изведен из пословне намере, а не из случајног покушаја поновног покушаја. На пример, <цоде>цреате-кеи:цустомер_123:прод:план_про је стабилна логичка операција. Нови поновни покушај исте операције требало би да је поново употреби. Каснија операција за креирање другог кључа за друго окружење треба да користи другачији кључ идемпотенције.<п>Ваша локална књига операција треба да складишти метод захтева, крајњу тачку, кључ идемпотенције, ИД спољног клијента, хеш терета, ИД захтева мрежног пролаза, статус одговора и коначни исход. Овај запис је мост између вашег механизма тока посла и мрежног пролаза. Такође даје тимовима за подршку и финансије начин да одговоре шта се догодило када је радник пао, дошло је до временског ограничења мреже или клијент тврди да је прилагодба кредита примењена два пута.<х2>Употреба, мерење и обрачун<п>Наплата заснована на АИ коришћењу треба да се заснива на нормализованим записима, а не снимцима екрана на контролној табли или широким фактурама добављача. Корисна књига коришћења укључује ИД захтева, ИД клијента, ИД кључа, ИД групе, модел, крајњу тачку, режим, статус, токен и анализу цена, временску ознаку и стање поравнања.Тамо где је релевантно, требало би да сачува категорије токена као што су улаз, излаз, кеширани унос, употреба алата, групни режим или прилагођавања специфична за провајдера.<п>Новац, кредити, стања, множитељи и количине коришћења треба да се анализирају као тачне децимале. Модел Гате документује финансијска поља и поља коришћења у свом Партнер АПИ-ју као ЈСОН децимални низови и упућује имплементаторе да користе децималне аритметичке аритметике произвољне прецизности уместо бинарног помичног зареза. Тај дизајн избегава мале грешке заокруживања које постају видљиве у фактурама, приказима преосталог стања и калкулацијама марже препродавца.<п>Наплата са мерењем у стилу траке има сличне захтеве: експлицитне идентификаторе купаца, вредности коришћења, временске ознаке, димензије и идентификаторе идемпотенције. Ако експортујете коришћење мрежног пролаза у екстерног добављача наплате, немојте прерано сажимати превише детаља. Можете да наплаћујете поједностављену јединицу, али вам је и даље потребно довољно порекла да ускладите евиденцију захтева, трансакције стања, фактуре, рефундације и карте за корисничку подршку.<п>За тимове који дизајнирају планове и марже, мерење партнера се директно повезује са <а хреф="/ен/">наплатом за АИ АПИ. Мрежни пролаз може да нормализује приступ моделу и аналитику коришћења, али препродавцу су и даље потребни каталог цена, датуми ступања на снагу, политика заокруживања, правила о порезу и фактурама и посао усаглашавања који упоређује локалну употребу, стање мрежног пролаза, трансакције стања, догађаје повратног позива и записе добављача наплате.<х2>Ограничења потрошње, <х2>Ограничења потрошње,<х2>Ограничења потрошње,<х2>Ограничења потрошње,<х2>Ограничења потрошње,<2> производи често захтевају строге контроле. Контролне табле добављача могу да нуде буџете или упозорења, али упозорења нису исто што и строга примена. Ограничења потрошње неких пројеката добављача су меки прагови. Они обавештавају или усмеравају понашање, али можда неће зауставити употребу на граници корисника коју је ваш производ обећао.<п>Партнерски АПИ би требало да вам омогући да примените ограничења према клијенту, кључу, групи, плану или класи модела. Препаид кредите је лакше ограничити јер је преостали износ изричит. Постпаид фактурисање може одговарати набавкама предузећа, али захтева јаче откривање аномалија, контролу кредита и токове наплате. Чврста ограничења штите маржу препродавача, али могу прекинути радна оптерећења купаца. Мека упозорења смањују сметње, али могу дозволити прекомерну потрошњу.<п>Ограничења стопе такође захтевају јасно власништво. Купац може достићи ограничење на нивоу препродавца, ограничење на нивоу мрежног пролаза или ограничење упстреам добављача. Ваша документација окренута клијентима треба да објасни како се поступа са ХТТП 429 одговорима, посебно понашањем <цоде>Покушај поново. Модел Гате документује одговоре са ограничењем брзине са заглављима ХТТП 429, <цоде>Ретри-Афтер и <цоде>Кс-РатеЛимит. Клијенти би требало да се повуку у складу са тим заглављима уместо да одмах покушају поново и стварају скокове оптерећења или вишак потрошње.<х2>Историја захтева, пагинација и задржавање<п>Записи недавних захтева су корисни за подршку, отклањање грешака и краткорочно усклађивање. Они нису замена за сталну финансијску базу података осим ако приступник експлицитно не обећава тај модел задржавања. Третирајте АПИ-је историје захтева као оперативне прозоре. Извезите и сачувајте записе који су вам потребни за обрачун, ревизију, подршку и аналитику.<п>Партнерски АПИ-ји обично користе пагинацију курсора за крајње тачке прикупљања. Ограничење докумената модела капије плус непрозирна пагинација курсора и временске ознаке УТЦ РФЦ3339. Курсоре треба третирати као непрозирне токене. Немојте их правити ручно, чувати пословно значење унутар њих или правити логику наплате која поприма облик курсора. Ваш извозник треба да запамти последњу успешну контролну тачку, безбедно рукује дуплираним записима и усаглашава према ИД-у захтева, а не само према позицији странице.<п>Прозори задржавања такође утичу на подршку. Ако клијент пита за фактуру од пре два месеца, ваш одговор не би требало да зависи од тога да ли крајња тачка недавног захтева још увек има необрађени догађај. Чувајте трајне метаподатке који су вам потребни: клијент, кључ, група, модел, ИД захтева, статус, количине коришћења, поравнати трошак, временска ознака и мапирање фактура.<х2>Повратни позиви, анкетирање и асинхронизовано закључивање<п>Асинхронизовано закључивање треба да се моделује као првокласни ток посла. Дуготрајни задаци слике, звука, серије или послови са великим бројем алата могу вратити ИД посла пре него што буду познати коначна употреба и цена. Партнерски систем треба да складишти послани посао, анкету или прима повратне позиве, да управља обрадом, завршеном, неуспешном, истеклом и отказаном стању, као и обрачун у складу са политиком коначног поравнања.<п>Позивање је једноставније за имплементацију и лакше за тестирање. Повратни позиви смањују кашњење и избегавају непотребно оптерећење анкетирања, али захтевају верификацију потписа, заштиту од понављања, дедупликацију, руковање поновним покушајем и обраду мртвог писма. Пропуштени повратни позиви не би требало да стварају трајне празнине у наплати.Радник за усаглашавање треба да упореди стање асинхронизованог посла, догађаје повратног позива, историју захтева и трансакције стања.<п>Модел Гате документује асинхронизовано испитивање резултата у Партнер АПИ-ју и понашање повратног позива у својој АПИ документацији. У производу препродавача, те могућности треба да буду умотане у отпоран модел испоруке. Клијенти треба да виде јасно стање посла и коначни резултат, док позадинска страна партнера чува оперативне детаље потребне за подршку и фактурисање.<х2>Апстракција добављача без губитка порекла<п>Гејтвеј са више модела може да сакрије непотребне разлике између добављача од купаца. То је драгоцено када желите један интерфејс компатибилан са ОпенАИ, један однос обрачуна и један оперативни модел међу провајдерима. Али апстракција не би требало да избрише порекло. И даље морате да знате који провајдер, модел, крајња тачка, режим захтева и категорије токена су довели до трошкова или неуспеха.<п>Ово је посебно важно када добављачи мењају цене, застаревају моделе, мењају ограничења стопе или излажу различиту семантику администратора. ОпенАИ пројекти, Антхропиц радни простори, кључеви клауд АПИ гатеваи-а и виртуелни кључеви АИ мрежног пролаза треће стране решавају повезане проблеме, али не откривају идентичне контроле. Контролној равни препродавца је потребан сопствени нормализовани модел и треба да третира поља специфична за добављача као порекло које подржава отклањање грешака, одговор на инциденте, поверење корисника и планирање миграције.<п>Дизајн плана се такође укршта са <а хреф="/ен/топицс/аи-модел-селецтион/">избором АИ модела. Купци могу купити једноставан ниво, али ваш бацкенд може усмеравати захтеве кроз моделе на основу квалитета, кашњења, цене, региона или доступности. Сачувајте довољно детаља да објасните те изборе када се трошкови промене или резултати разликују.<х2>Контроле подршке и злоупотребе<п>Токови рада подршке треба да буду дизајнирани пре првог инцидента са клијентом. Оператери треба да прегледају недавне метаподатке захтева, идентификују који клијент и кључ су изазвали пораст, замрзну или одмрзну приступ, ротирају акредитиве, померају кључ између група, подесе ограничења где је то уговорно прикладно и сачувају догађаје ревизије за сваку радњу.<п>Добра конзола за подршку подразумевано не мора да излаже необрађене упите. Уочљивост на првом месту метаподатака обично пружа довољно контекста за фактурисање и оперативну тријажу уз истовремено смањење ризика приватности и задржавања. Ако се сирови садржај складишти или проверава, дефинишите контроле приступа, периоде задржавања, обавештења корисника и евиденцију ревизије.<п>Контроле злоупотребе треба да буду прецизне. Замрзавање једног кључа не би требало да суспендује неповезане станаре. Бучни купац не би требало да исцрпи стање на заједничком рачуну или капацитет провајдера за сваког другог корисника. Контроле на нивоу групе и на нивоу кључа чине одговор бржим и мање ометајућим.<х2>Бела етикета, ко-брендирани или транспарентни приступ<п>Продавци морају да одлуче колико клијент зна о основном мрежном пролазу и добављачима модела. АИ АПИ са белом етикетом може да представља само бренд препродавца. Кобрендирана услуга може открити мрежни пролаз или провајдера. Транспарентна понуда предузећа може да покаже порекло модела, регионе добављача и детаљне категорије коришћења.<п>Не постоји један тачан одговор. Сакривање детаља може учинити производ купца једноставнијим. Откривање детаља може побољшати поверење, набавку, преглед усклађености и управљање инцидентима. Оно што је важно је доследност. Фактура, процес подршке, политика прихватљиве употребе, језик ограничења брзине и обавезе у вези са руковањем подацима треба да одговарају начину на који је приступ представљен.<х2>Уобичајене грешке<п>Најчешћи неуспех је коришћење једног дељеног АПИ кључа за многе клијенте. Ово функционише све док не дође до спора око наплате, извештаја о злоупотреби, повећања кашњења, проблема са квотом или догађаја одлива клијената. Без акредитива за клијента, свака истрага постаје нагађање.<п>Још једна честа грешка је поновни покушај мутирајућих операција без идемпотенције. Временска ограничења су двосмислена. Операција је можда успела чак и ако ваш радник није добио одговор. Стабилни кључеви идемпотенције и локална оперативна књига спречавају дуплирање кључева, кредита и промене стања.<п>Грешке у заокруживању је такође лако потценити. Рашчлањивање децималног новца и поља за коришћење као бројева са покретним зарезом може да створи мале разлике које се акумулирају на свим фактурама. Користите децималну аритметику произвољне прецизности за кредите, стања, множиоце и измирене трошкове.<п>Тимови такође верују у буџете добављача. Упозорења и ограничења на нивоу пројекта можда неће применити строга ограничења на нивоу корисника обећана у плану препродавача. Примените ограничења на слоју мрежног пролаза или партнера где је то могуће, а затим помирите плаћену употребу након завршетка.<п>Коначно, не правите обрачун само на основу укупних износа. Укупни износи су корисни резимеи, али за фактуре су потребне одбрамбене линије.ИД-ови захтева за складиштење, ИД-ови корисника, ИД-ови захтева за пролаз, детаљи о коришћењу, евиденција трансакција, ИД-ови догађаја наплате и стања поравнања.<х2>Контролна листа за имплементацију<п>Почните са животним циклусом корисника. Дефинишите како се клијент креира, надограђује, суспендује, поново активира, ротира и брише. Мапирајте свако стање на партнерске АПИ операције и локалне догађаје ревизије.<п>Следеће, дизајнирајте књигу операција. Сваки променљиви захтев за АПИ партнера треба да има стабилан кључ идемпотенције, хеш корисног оптерећења, ИД захтева мрежног пролаза где је доступан, статус одговора, број поновних покушаја и коначни исход. Ова књига је окосница поуздане партнерске АПИ аутоматизације.<п>Затим направите извоз коришћења и усаглашавање. Извоз захтева и записа трансакција по распореду. Користите тачне децимале. Проверите да ли недостају догађаји, дуплиране пријаве за обрачун, нерешене асинхронизоване послове, грешке повратног позива и неподударања фактура.<п>Након тога, пажљиво изложите приказе самопослуживања клијената. Прикажи коришћење, преостали буџет, тренутне кључеве, опције ротације, ограничења и недавне грешке. Немојте откривати акредитиве добављача или неповезане податке станара. Учините радње подршке подложним ревизији и реверзибилним где је то могуће.<п>На крају, документујте поновни покушај са клијентом и ограничите понашање. Објасните руковање 429, очекивања ротације кључева, стања асинхронизованих послова, кашњење у извештавању о коришћењу и разлику између чврстих ограничења, меких упозорења, ограничења за препродаваче, ограничења мрежног пролаза и ограничења упстреам провајдера.<х2>Закључак<п>АПИ партнера и препродавца је контролна раван која претвара приступ моделу АИ производа. Требало би да креира акредитиве на нивоу корисника, да их организује у групе или планове, да примени контролу потрошње и стопе, да разоткрије евиденцију о коришћењу и трансакцијама, да подржи асинхронизоване токове посла и да обезбеди операције подршке као што су ротација, замрзавање и усаглашавање.<п>Централни принцип је једноставан: сваком обећању које је окренуто клијенту је потребан трајни позадински објекат и ревизијски траг. Ако обећате одвојено обрачунавање, направите засебно приписивање. Ако обећате буџет, извршите га и ускладите. Ако поново покушате операције, учините их идемпотентним. Ако фактуришете коришћење, сачувајте тачне децималне записе и порекло на нивоу захтева.<п>Модел Гате Партнер АПИ могућности су релевантне јер се баве радом на контролној равни око вишемоделног мрежног пролаза компатибилног са ОпенАИ: аутентификација сервер-сервер, АПИ кључ и аутоматизација групе, употреба децималног броја и резултат биланса, финансијска поља, захтеви за историју трансакција, захтеви за историју трансакција и захтеви одговори са ограничењем брзине, повратни позиви, обједињени обрачун, управљање АПИ кључевима, аналитика коришћења и контроле тима. Пажљиво коришћени, ови примитивци дозвољавају агенцијама, СааС тимовима и препродавцима да пакују приступ АИ АПИ-ју без одрицања контроле наплате или оперативне одговорности.