Начнём с глобального 

1. API должен отдавать данные в формате JSON.
Соответственно MIME-тип отдаваемых данных -- application/json:

header('Content-type: application/json');

Преимущества: данный формат наиболее прост в использовании на стороне клиента, небольшой объём "лишних" данных.
Мультиформатность, не дав ничего уникального, может только отдалить во времени создание API.

2. Адрес доступа к API -- /api.php?argument=value
Например для этого форума полный адрес доступа к API  будет таким:

http://forum.mybb.ru/api.php

Коротко и понятно.

3. В сигнатуре вызова функций, вид данных, который нужно получить, передаётся через аргумент data.
Пример:

http://forum.mybb.ru/api.php?data=forum

Возвращает информацию о форуме.

4. В целях безопасности экранировать слешами всё опасное в данных возвращаемых сервером клиенту.
Особенно важно экранировать eval() в тексте названий тем, тексте сообщений, логинах юзеров и т.д.

1. Доступ к информации о форуме и его настройках

Аргумент -> data
Значение -> forum

Возвращает строку со всей доступной информацией.

Пример:
Запрос:

http://forum.mybb.ru/api.php?data=forum

Ответ:

{"ключ":"значение","ключ":"значение" и т.д.}

Используемые ключи:
boardId - идентификационный номер форума
boardCat - категория форума в каталоге
boardStyle - название стиля форума или custom, если используется свой стиль  (именно стиль в настройках форума - один из готовых или custom, без учёта настройки стиля в профиле, если запрос идёт )
timeForum - часовой пояс форума, если положительный сдвиг, то просто число, если отрицательный - с минусом.
timeCreate - время рождения форума - кол-во сек с начала эпохи UNIX в момент регистрации форума.
title - название форума
allUsers - количество участников
allTopics - количество тем
allPosts - количество сообщений
allCat - количество категорий
allForum - количество форумов
latestUserId - id последнего зарегистрированного юзера
latestUserName - логин последнего зарегистрированного юзера
activeGuest - кол-во гостей онлайн
activeUsers - кол-во пользователей онлайн
activeRecord - рекорд количества посетителей
activeDate - дата рекорда количества посетителей - кол-во сек прошедшие до начала по GMT дня рекорда с начала эпохи UNIX
foundation - 0 если фонд форума не используется, 1 - если используется, но ссылки на главной нет, 2 - используется и ссылка на главной есть
credits - возращает количество средств в фонде форума, или пустую текстовую строку если фонд не используется.
announcement - 0 если объявление не используется, 1 если используется везде, 2 - только на главной
showUserInfo - 0 если инфа об авторе сообщений не отображается, иначе 1
userStyle - 0 если нельзя юзеру выбрать стиль, иначе 1
usersOnline - 0 если не отображается на главной список юзеров онлайн, иначе 1
users24h - 0 если не отображается на главной стата от посещаемости за 24 часа (у партнёров должно быть значение равным 0), иначе 1
usersBirthday - 0 если именниники не отображаются на главной, иначе 1
statsOther - 0 если подробная статистика не отображается на главной, иначе 1
searchForums - 0 если поиск не включён, иначе 1
postRating - 0 если рейтинг поста не отображается, иначе 1
avatars - 0 если аватары не разрешено использовать, иначе 1
subscriptions - 0 если зарещены подписки, иначе 1
relation - 0 если отключена система отношений, 1 если + и -, 2 если сумма + и -, 3 если только +.

Получение только нужных данных
Это возможно при использовании доп. аргументов со значением 1.

Примеры:
Запрос:

http://forum.mybb.ru/api.php?data=forum&boardId=1

Ответ:

{"boardId":"5148"}

Запрос:

http://forum.mybb.ru/api.php?data=forum&boardId=1&boardCat=1

Ответ:

{"boardId":"5148","boardCat":"3"}

P.S.: конечно можно устроить дискуссию, насчёт того что некоторые значения уже выводятся в Javascript-переменных форума.
Но я делаю расчёт на использование доступа к инфе со сторонних сайтов. Мне бы пригодилось для сайта сервиса, т.к. сейчас приходится cUrl'ом получать контент страницы форума и из исходного кода выпарсивать эти самые Javascript-переменные, что естественно создаёт  на сервера МуВВ лишнюю нагрузку - не нужную ни Admin'y, ни мне.

Лучше ты свою страту сформулируй, и опубликуй здесь, а затем посмотрим что скажет Admin о твоём варианте и моём.

Из-за распространения этих скриптов растёт нагрузка в основном зря.

Если создать API, и соответственно скрипты работающие благодаря ему,  то нагрузка при использовании новых скриптов не будет сильно расти. И эта нагрузка будет эффективной, т.к. данные передаваемые через API будут полностью использоваться, в отличии от того что происходит сейчас. Плюс часть старых скриптов будет заменена новыми - результатом будет снижение нагрузки.

И вообще - новые скрипты станет проще создавать

Опять же, если будет реализовано API в желаемом мной виде, я сделаю цветовыделение логинов по группам