If you haven’t already an understanding of the following concepts, we encourage you to do a little preliminary reading before moving on. Here are some of the things you should know and how they relate to your integration with eQuest.
If you’re a developer you’re likely fairly familiar with this protocol — but it’s worth mentioning to emphasize our integration’s dependency on proper, well-formed HTTPS requests.
eQuest can handle job information in any written language, by storing all of our job data in the UTF-8 character set. However, in order for your request payload to be properly received, it must be encoded in one of the following character sets. You should understand the differences between these specifications and the nature and encoding of your own data.
Users need to publish presentable requisitions, and HTML allows them to do that.
In most case, the markup is transparent to the user — they either copy and paste formatted data from a third party application such as Microsoft Word, or they use a WYSIWYG editor embedded in your application. A common side effect of this indirect composition is untidy markup — empty <p> tags, unnecessary entities, etc.
We’ve designed our application to maintain as much of our users’ intended formatting as possible, and our translation toolset provides a handful of effective methods to do so. For boards that accept any HTML markup we pass through the given data with no modification unless the transport format — such as tab or pipe delimited — requires it. For boards that don’t accept any HTML, we render the markup — as a user would see it in a web browser — and pass through a text representation of the resulting format. For boards that accept only a subset of HTML, we can selectively render only the fragments of unsupported markup, and keep the supported markup intact.