PolyAPI  >  Learn More  >  Release Notes

PolyAPI – Release 6

Release Notes

November 16, 2023
Days since last production release: 42 Days

New Features

  • Exposed training source data to be viewable and editable via Poly’s management APIs. Users now don’t have to retrain functions, but can rather patch the source data to adjust the behavior. Additionally, users can now see the source data and use it for debugging or better understanding of how an API works. In the future this data may be used to generate OpenAPI specs, or provide users direct API support in the Poly Assistant if demanded by customers. 
  • Added support for public webhooks handler functions. Now a Poly user can train Poly on webhooks and expose it for all users to use. Poly will have different environment specific endpoints to handle webhook events to allow each environment to point their webhook events to their environment specific endpoints. 
  • Exposed response type schema via Poly’s management API. Users can now see and edit the type schema directly via the API. This will be used in the future for automated recommendations by a runtime observer to allow for real-time API drift detection and reinforced self learning from production traffic. 
  • Improved our VS Code extension to help users install needed runtime, language, compiler, and package manager dependencies on a per project basis.
  • Referencing of type definitions from API functions (training) within custom functions to allow all the object type definitions to be used in new microservices on top of the APIs which are trained to Poly. 
  • Ability for Super Admins (deployment instance admins) to configure custom functions to either never go to sleep or to change the sleep interval. This will likely be only reserved for self-service instances. We will likely roll out this capability to tenant admins and maybe users depending on customer feedback and need. 
  • Ability to pass the execution key as an argument into a custom function and have the function run within the environment context of that execution key. This allows for really clean Multi-Tenant implementations with Vari where the risk of cross tenant data contamination is architecturally eliminated. 
  • Added an optional training script for webhooks which allows commenting on the event payload to annotate the type definitions of objects to be included in our library.
  • Added support for general documentation to be included as part of the content that Poly can use to help users. /d now routes to customer specific documentation which can be used for any generic content that customers feel is relevant to developers building integrations against their APIs. This can be tutorials, guides, explanation, FAQ, finding the right contacts or files, etc… 
  • Support for Java client generation using Maven. Also extended our VS code extension to pass in the last opened supported file type in this project to the AI service so we can take an educated guess and generate sames in the language being used, supported by Poly. This first release there are a few limitations compared to our TypeScript library:
    • No Support for custom functions in Poly Library or Poly Server written in Java. 
    • No Support for a setup experience yet. The import is done by updating the pom file and running mvn clean compile.  
  • Added an endpoint /functions/server/{id}/logs where custom logs from server functions can be viewed. Added a configuration on server functions to determine if logs are being persisted and a default log setting on environments which determines what setting functions deployed to that environment are initialized to. 
  • Deployed our first instance in Azure. 

Improvements and Bug Fixes

  • Fixed a bug with Auth-Provider where revoking an expired Auth Token and getting a new one was not working as expected.
  • Enhanced training to account for APIs which don’t ignore empty optional payload elements.
  • Fixed a bug where, at the time of training, types were assigned based on the value of a variable and not the it’s type. For example “foo”:“123” was considered as a number by Poly. 
  • At the time of training, optional payload parameters can now be designated as such by using a ? as the first character after //. For example: “foo”:”123” //? some comment
  • When a webhook or inbound API request is being processed, if a security function rejects the request and sets the response code, we will now return the status code of that security function to the originator of the API/Webhook event.
  • Refresh tokens held by Poly in conjunction with Poly Auth-Provider functions are now stored within Hashicorp Vault vs previously being stored in a custom credential store. 
  • Optimized how we use OpenAI for API discovery within our AI assistant to make it faster. 
  • Fixed a bug in the IDE where after using Poly’s extension to configure the client and generate a library, our extension was still incorrectly asking users to set credentials.
  • Switched the copy action for variables within Vari to copy .inject() statements instead of .get() statements. 
  • Cleaned up our GET /webhooks endpoint to reduce only data relevant to collections. 
  • Refactored our conversation history service to allow full conversation ID freedom within each environment. 
  • Introduced a version to our Postman training scripts and a server check to warn users when they are using out of date Postman training scripts. 
  • Fixed a bug where corrupted function type schema was causing the whole library to not work for all users within an environment. Now if type schemas are corrupted (likely by a mistake when Patching type schemas), those specific functions will be skipped at library generation instead of the whole library failing to generate. 
  • Decoupled key permissions for library generation form execution. This way if a key which has the right to execute functions is compromised, that key cannot be used to generate a library (assuming it was scoped to execution which is a best practice for runtime keys) and see all the functions within the environment. This reduces the surface area of attackers in the case they get a hold of a Poly key. 
  • Improved the default view configuration of Poly after installing our extension. This improves the onboarding experience for new users installing Poly VS code extension for the first time. 
  • Ability for tenants admins to set their own OpenAI keys. This is needed for self-hosted instances to use their own OpenAI Accounts. This also allows different lines of business or teams within an enterprise to use different OpenAI API keys. 
  • Fixed a bug where training an API with a collection created enum types for the data identified in the various objects. Now we only generate the schema and the example data is not saved. 
  • Fixed a bug where null arguments for optional arguments for API functions were not handled properly and were causing an error to be thrown instead of passed through as undefined. 
  • Fixed a bug where executing a custom server function within a few seconds of a deploy was causing 404 errors.