Latest improvements to the flexmls API

by Greg Kilwein on July 12, 2011

in flexmls API

We are once again happy to announce some improvements to the flexmls API that were released this morning. There are many improvements this time, so the changes have been categorized below into those that affect listings and those that affect other services. A special thank-you goes again to my team for turning the project plan ideas into reality.

Improvements to listings and searching in general:

  • A new search-only listing field called StreetAddress is now accepted on the _filter parameter of the Listings service. This parameter allows the first line of the street address to be searched by user-entered text without decomposing the user’s search string into the individual address components like StreetName.
  • The following agent fields have been added to the supported _filter fields of the Listings service to facilitate searching listings by agent: ListAgentId, CoListAgentId, BuyerAgentId, CoBuyerAgentId
  • The ListingId field in the Listings service, which is more commonly known as MLS Number, now allows multiple numbers to be specified when searching on that field. For example: _filter=ListingId Eq '4385959','4398484'
  • Any service that supports the _filter parameter for searching now supports one level of parameter nesting with parentheses. For example, this allows the Listings service to be queried like the following: (ListingId Eq '11-13') Or (ListingId Eq '11-12' And ListAgentId Eq '20010202184033129791000000')
  • The Listing search parameters now support searching by shared listing ID, which is returned by the Shared Listings Service after creating a sharing listing record using the POST method.

Improvements to other services:

  • The Accounts service previously consisted of only the My Account service. It has been broadened to encompass all user accounts, so new service paths have been added. The MLS’s user roster may now be searched by user type, name, email, and other fields.
  • If your API key has an IDX role and has used OAuth to log in as a portal user (an agent’s customer), the My Account service now returns whether that user has signed up to get daily email updates on new and changed listings.
  • The Contacts and Listing Carts services now are paginated using the standard pagination syntax.
  • Carts for portal users (an agent’s customer) are now available in the Listing Carts service.
  • The MLS’s currency type (US Dollars, etc.) is now returned via the System Info service.

We hope these improvements allow you to develop richer applications using the flexmls API.


Max Chirkov July 21, 2011 at 12:50 pm

I wasn’t sure where to post it, so I decided to do it here:

Since you guys have your official PHP API wrapper, there is no point for anyone else to fork & maintain their own with most current methods reflecting API Services. But I noticed that the wrapper is outdated – missing the latest services. If you continue to maintain the PHP file, I’d recommend making a few adjustments where it could be easily extended with custom methods. I’m not a PHP guru, but the only barrier I’m seeing so far is a Private property – $api_version. I think you need to make it public or protected in order to let the class being extended with new methods.

It seems like it’s much easier to have custom extensions of this class to integrate with any third party apps like WordPress or Drupal, than forking the wrapper and making new branches for each project.

Greg Kilwein July 22, 2011 at 1:15 pm

Thanks, Max. I sent your ideas on to the developer who wrote the PHP client. I agree that the client FBS is developing would would be best if it remained the central client, rather than having each developer fork their own.

Greg Kilwein July 27, 2011 at 10:56 am

Max, a quick follow-up comment here. If you have already implemented your ideas for improvements to the flexmls API’s PHP client, feel free to issue a pull request on the flexmls github account for the PHP client. We’ll review it and merge changes if we think they benefit the client. That’s easier than trying to describe the changes here and having us make them.

As a clarification to my earlier statement about forking, we encourage developers to fork our code, but also encourage them to issue pull requests for changes that they think would benefit everyone using the client.

Thanks again for the feedback!

Max Chirkov July 28, 2011 at 12:57 pm

Thanks Greg! Will do.

Max Chirkov July 28, 2011 at 1:21 pm

Just FYI: the PHP API wrapper is licensed under Apache v.2, which is compatible with GPL 3, but not compatible with GPL 2. WordPress requires GPL 2 compatibility in order to host third party plugins in their public repository at

Here is the resources:

Greg Kilwein July 28, 2011 at 3:32 pm

Max, the PHP API client inside of the flexmls IDX WordPress plugin is released under a GPL v2 license. The PHP API client as distributed separately on github is released under the Apache v2 license. I looked inside of the distribution file on and couldn’t find any reference to an Apache license; if any Apache v2 license exists inside the WP plugin, let me know and we’ll fix it.

Max Chirkov July 28, 2011 at 3:53 pm

Greg, I was referring to GitHub version since this is what I’m using to extend my existing WordPress plugin.

Greg Kilwein July 29, 2011 at 7:41 am

Max, I’ll follow up separately by e-mail to get more details to make sure I understand.

Max Chirkov August 31, 2011 at 12:22 pm

Hey guys,

SubdivisionName field is listed as searchable, but it returns 0 records every time I try it. I also see that the data in the field is blacked-out with ********* when general search results are returned. Is this a bug or still in development?

Greg Kilwein August 31, 2011 at 3:46 pm

Max, SubdivisionName is mapped to Legal Subdivision in your MLS, which is a field that the MLS has chosen to not make available for IDX. That’s why it’s masked.

Max Chirkov September 1, 2011 at 11:06 am

Greg, then having field attribute “searchable” = true is actually wrong. I can’t automatically determine which field is actually searchable and which is not. Any further thoughts on this?

Greg Kilwein September 1, 2011 at 2:42 pm

Good point, Max. We’ll think about a way to handle this situation. While the field is technically still searchable (it doesn’t throw an error when searching it), it’s not useful to search by a masked field.

Max Chirkov September 1, 2011 at 4:08 pm

I’m trying to build a logic where user can generate a shortcode with a custom search. The shortcode attributes are dynamic, depending on the API’s searchable fields. Then attributes get automatically parsed into the API query, depending on their respective field types. Right now bunch of searchable fields return 0 results. I understand that they will vary form MLS to MLS, but that’s why it’s better to have dynamic logic solely based on the API, than statically pre-set available searchable fields. Otherwise we’ll get flooded with emails and phone calls from frustrated agents from all over the US 🙂

Greg Kilwein September 1, 2011 at 4:13 pm

Makes sense. Part of the issue is that the MLS can make a specific field available (or not) to IDX recipients based on property type, so it’s possible for Subdivision to be available in one property type but not another. We’ll keep your use cases in mind as we work on this.

Comments on this entry are closed.

Previous post:

Next post: